Interoperable systems and methods for peer-to-peer service orchestration

ABSTRACT

Systems and methods are described for performing policy-managed, peer-to-peer service orchestration in a manner that supports the formation of self-organizing service networks that enable rich media experiences. In one embodiment, services are distributed across peer-to-peer communicating nodes, and each node provides message routing and orchestration using a message pump and workflow collator. Distributed policy management of service interfaces helps to provide trust and security, supporting commercial exchange of value. Peer-to-peer messaging and workflow collation allow services to be dynamically created from a heterogeneous set of primitive services. The shared resources are services of many different types, using different service interface bindings beyond those typically supported in a web service deployments built on UDDI, SOAP, and WSDL. In a preferred embodiment, a media services framework is provided that enables nodes to find one another, interact, exchange value, and cooperate across tiers of networks from WANs to PANs.

RELATED APPLICATIONS

This application is a division of U.S. application Ser. No. 11/894,624,filed Aug. 20, 2007, which is a continuation of U.S. application Ser.No. 10/863,551, filed Jun. 7, 2004, which claims the benefit of U.S.Provisional Applications Nos. 60/476,357, filed Jun. 5, 2003, entitledSystems and Methods for Peer-To-Peer Service Orchestration, attachedhereto as Appendix 1(A), and 60/504,524, filed Sep. 15, 2003, entitledDigital Rights Management Engine Systems and Methods, attached hereto asAppendix 1(B), all of which are incorporated herein by reference.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

Networks such as the Internet have become the predominant medium for thedelivery of digital content and media related services. The emergence ofstandard web services protocols promises to accelerate this trend,enabling companies to provide services that can interoperate acrossmultiple software platforms and support cooperation between businessservices and consumers via standardized mechanisms.

Yet, significant barriers exist to the goal of an interoperable andsecure world of media-related services. For example, multiple,overlapping de facto and formal standards can actually inhibitstraightforward interoperability by forcing different implementations tochoose between marginally standard, but otherwise incompatible,alternative technical approaches to addressing the same basicinteroperability or interconnection problems. In some cases theseincompatibilities are due to problems that arise from trying tointegrate different generations of technologies, while in other casesthe problems are due to market choices made by different partiesoperating at the same time but in different locales and with differentrequirements. Thus, despite standardization, it is often difficult tolocate, connect to, and interact with devices that provide neededservices. And there are frequently incompatibility issues betweendifferent trust and protection models.

While emerging web service standards such as WSDL (Web ServicesDescription Language) are beginning to address some of these issues forInternet-facing systems, such approaches are incomplete. They fail toaddress these issues across multiple network tiers spanning personal andlocal area networks; home, enterprise, and department gateways; and widearea networks. Nor do they adequately address the need forinteroperability based on dynamic orchestration of both simple andcomplex services using a variety of service interface bindings (e.g.,CORBA, WS-I, Java RMI, DCOM, C function invocation, .Net, etc.), thuslimiting the ability to integrate many legacy applications. The adventof widely deployed and adopted peer-to-peer (P2P) applications andnetworks further compounds the challenges of creating interoperablemedia-related services, due in part to the fact that there is no unifiednotion of how to represent and enforce usage rights on digital content.

SUMMARY

Embodiments of the systems and methods described herein can be used toaddress some or all of the foregoing problems. In one embodiment, aservices framework is provided that enables multiple types ofstakeholders in the consumer or enterprise media space (e.g., consumers,content providers, device manufacturers, service providers) to find eachother, establish a trusted relationship, and exchange value in rich anddynamic ways through exposed service interfaces. Embodiments of thisframework—which will be referred to generally as the Network Environmentfor Media Orchestration (NEMO)—can provide a platform for enablinginteroperable, secure, media-related e-commerce in a world ofheterogeneous consumer devices, media formats, communication protocols,and security mechanisms. Distributed policy management of the serviceinterfaces can be used to help provide trust and security, therebyfacilitating commercial exchange of value.

While emerging web service standards are beginning to addressinteroperability issues for Internet-facing services, embodiments ofNEMO can be used to address interoperability across multiple networktiers spanning personal and local area networks; home, enterprise, anddepartment gateways; and wide area networks. For example, NEMO canprovide interoperability in one interconnected system using cell phones,game platforms, PDAs, PCs, web-based content services, discoveryservices, notification services, and update services. Embodiments ofNEMO can further be used to provide dynamic, peer-to-peer orchestrationof both simple and complex services using a variety of local and remoteinterface bindings (e.g. WS-I[1], Java RMI, DOOM, C, .Net, etc.),thereby enabling the integration of legacy applications.

In the media world, the systems and interfaces required or favored bythe major sets of stakeholders (e.g., content publishers, distributors,retail services, consumer device providers, and consumers) often differwidely. Thus, it is desirable to unite the capabilities provided bythese entities into integrated services that can rapidly evolve intooptimal configurations meeting the needs of the participating entities.

For example, diverse service discovery protocols and registries, such asBluetooth, UPnP, Rendezvous, JINI, UDDI, and LDAP (among others) cancoexist within the same service, enabling each node to use the discoveryservice(s) most appropriate for the device that hosts that node. Anotherservice might support IP-based as well as wireless SMS notification, orvarious media formats (MP4, WMF, etc.).

Embodiments of NEMO satisfy these goals using peer-to-peer (P2P) serviceorchestration. While the advantages of P2P frameworks have been seen forsuch things as music and video distribution, P2P technology can be usedmuch more extensively.

Most activity in web services has focused on machine-to-machineinteraction with relatively static network configuration and clientservice interactions. NEMO is also capable of handling situations inwhich a person carries parts of their personal area network (PAN), movesinto the proximity of a LAN or another PAN, and wants to reconfigureservice access immediately, as well as connect to many additionalservices on a peer basis.

Opportunities also exist in media and various other enterprise services,and especially in the interactions between two or more enterprises.While enterprises are most often organized hierarchically, and theirinformation systems often reflect that organization, people fromdifferent enterprises will often interact more effectively through peerinterfaces. For example, a receiving person/service in company A cansolve problems or get useful information more directly by talking to theshipping person in company B. Traversing hierarchies or unnecessaryinterfaces generally is not useful. Shipping companies (such as FedExand UPS) realize this and allow direct visibility into their processes,allowing events to be directly monitored by customers. Companies andmunicipalities are organizing their services through enterprise portals,allowing crude forms of self-service.

However, existing peer-to-peer frameworks do not allow one enterprise toexpose its various service interfaces to its customers and suppliers insuch a way as to allow those entities to interact at natural peeringlevels, enabling those entities to orchestrate the enterprise's servicesin ways that best suit them. This would entail, for example, some formof trust management of those peer interfaces. Preferred embodiments ofthe present invention can be used to not only permit, but facilitate,this P2P exposure of service interfaces.

In the context of particular applications such as DRM (Digital RightsManagement), embodiments of NEMO can be used to provide aservice-oriented architecture designed to address the deficiencies andlimitations of closed, homogeneous DRM systems. Preferred embodimentscan be used to provide interoperable, secure, media-related commerce andoperations for disparate consumer devices, media formats, and securitymechanisms.

In contrast to many conventional DRM systems, which require relativelysophisticated and heavyweight client-side engines to handle protectedcontent, preferred embodiments of the present invention enableclient-side DRM engines to be relatively simple, enforcing thegovernance policies set by richer policy management systems operating atthe service level. Preferred embodiments of the present invention canalso provide increased flexibility in the choice of media formats andcryptographic protocols, and can facilitate interoperability between DRMsystems.

A simple, open, and flexible client-side DRM engine can be used to buildpowerful DRM-enabled applications. In one embodiment, the DRM engine isdesigned to integrate easily into a web services environment, and intovirtually any host environment or software architecture.

Service orchestration is used to overcome interoperability barriers. Forexample, when there is a query for content, the various services (e.g.,discovery, search, matching, update, rights exchange, and notification)can be coordinated in order to fulfill the request. Preferredembodiments of the orchestration capability allow a user to view allhome and Internet-based content caches from any device at any point in adynamic, multi-tiered network. This capability can be extended topromote sharing of streams and playlists, making impromptu broadcastsand narrowcasts easy to discover and connect to, using many differentdevices, while ensuring that rights are respected. Preferred embodimentsof NEMO provide an end-to-end interoperable media distribution systemthat does not rely on a single set of standards for media format, rightsmanagement, and fulfillment protocols.

In the value chain that includes content originators, distributors,retailers, service providers, device manufacturers, and consumers, thereare often a number of localized needs in each segment. This isespecially true in the case of rights management, where contentoriginators may express rights of use that apply differently in variouscontexts to different downstream value chain elements. A consumergateway typically has a much more narrow set of concerns, and an enduser device may have a yet simpler set of concerns, namely just playingthe content. With a sufficiently automated system of dynamicallyself-configuring distribution services, content originators can produceand package content, express rights, and confidently rely on value addedby other service providers to rapidly provide the content to interestedconsumers, regardless of where they are or what kind of device they areusing.

Preferred embodiments of NEMO fulfill this goal by providing means formultiple service providers to innovate and introduce new services thatbenefit both consumers and service providers without having to wait foror depend on a monolithic set of end-to-end standards. Policy managementcan limit the extent to which pirates can leverage those legitimateservices. NEMO allows the network effect to encourage the evolution of avery rich set of legitimate services providing better value than piratescan provide.

Some “best practice” techniques common to many of the NEMO embodimentsdiscussed below include the following:

-   -   Separation of complex device-oriented and service-oriented        policies    -   Composition of sophisticated services from simpler services    -   Dynamic configuration and advertisement of services    -   Dynamic discovery and invocation of various services in a        heterogeneous environment    -   Utilization of gateway services from simple devices

A novel DRM engine and architecture is also presented that can be usedwith the NEMO framework. This DRM system can be used to achieve some orall of the following goals:

Simplicity. In one embodiment, a DRM engine is provided that uses aminimalist stack-based Virtual Machine (VM) to execute control programs(e.g., programs that enforce governance policies). For example, the VMmight consist of only a few pages of code.

Modularity. In one embodiment, the DRM engine is designed to function asa single module integrated into a larger DRM-enabled application. Manyof the functions that were once performed by monolithic DRM kernels(such as cryptography services) can be requested from the hostenvironment, which may provide these services to other code modules.This allows designers to incorporate standard or proprietarytechnologies with relative ease.

Flexibility. Because of its modular design, preferred embodiments of theDRM engine can be used in a wide variety of software environments, fromembedded devices to general-purpose PCs.

Open. Embodiments of the DRM engine are suitable for use as referencesoftware, so that code modules and APIs can be implemented by users invirtually any programming language and in systems that they controlcompletely. In one embodiment, the system does not force users to adoptparticular content formats or restrict content encoding.

Semantically Agnostic. In one embodiment, the DRM engine is based on asimple graph-based model that turns authorization requests into queriesabout the structure of the graph. The vertices in the graph represententities in the system, and directed edges represent relationshipsbetween these entities. However, the DRM engine does not need to beaware of what these vertices and edges represent in any particularapplication.

Seamless Integration with Web Services. The DRM client engine can useweb services in several ways. For example, vertices and edges in thegraph can be dynamically discovered through services. Content andcontent licenses may also be discovered and delivered to the DRM enginethrough sophisticated web services. Although one embodiment of the DRMengine can be configured to leverage web services in many places, itsarchitecture is independent of web services, and can be used as astand-alone client-side DRM kernel.

Simplified Key Management. In one embodiment, the graph topology can bereused to simplify the derivation of content protection keys withoutrequiring cryptographic retargeting. The key derivation method is anoptional but powerful feature of the DRM engine—the system can also, oralternatively, be capable of integrating with other key managementsystems.

Separation of Governance, Encryption, and Content. In one embodiment,the controls that govern content are logically distinct from thecryptographic information used to enforce the governance. Similarly, thecontrols and cryptographic information are logically distinct fromcontent and content formats. Each of these elements can be deliveredseparately or in a unified package, thus allowing a high degree offlexibility in designing a content delivery system.

Embodiments of the NEMO framework, its applications, and its componentparts are described herein. It should be understood that the frameworkitself is novel, as are many of its components and applications. Itshould also be appreciated that the present inventions can beimplemented in numerous ways, including as processes, apparatuses,systems, devices, methods, computer readable media, or a combinationthereof. These and other features and advantages will be presented inmore detail in the following detailed description and the accompanyingdrawings which illustrate by way of example the principles of theinventive body of work.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the inventive body of work will be readily understood byreferring to the following detailed description in conjunction with theaccompanying drawings, wherein like reference numerals designate likestructural elements, and in which:

FIG. 1 illustrates a sample embodiment of the system framework.

FIG. 2 a illustrates a conceptual network of system nodes.

FIG. 2 b illustrates system nodes in a P2P network.

FIG. 2 c illustrates system nodes operating across the Internet.

FIG. 2 d illustrates a system gateway node.

FIG. 2 e illustrates a system proxy node.

FIG. 2 f illustrates a system device adapter node.

FIG. 3 illustrates a conceptual network of DRM devices.

FIG. 4 illustrates a conceptual DRM node authorization graph.

FIG. 5 a illustrates a conceptual view of the architecture of a systemnode.

FIG. 5 b illustrates multiple service interface bindings supported bythe service adaptation layer of a system node.

FIG. 6 a illustrates basic interaction between a service-providingsystem node and a service-consuming system node.

FIG. 6 b is another example of an interaction between aservice-providing system node and a service-consuming system node.

FIG. 7 a illustrates a service access point involved in a client-sideWSDL interaction.

FIG. 7 b illustrates a service access point involved in a client-sidenative interaction.

FIG. 7 c illustrates a service access point involved in a service-sidepoint-to-point interaction pattern.

FIG. 7 d illustrates a service access point involved in a service-sidepoint-to-multiple point interaction pattern.

FIG. 7 e illustrates a service access point involved in a service-sidepoint-to-intermediary interaction pattern.

FIG. 8 illustrates an embodiment of the architecture of the serviceadaptation layer.

FIG. 9 a illustrates an interaction pattern of a workflow collatorrelying upon external service providers.

FIG. 9 b illustrates an interaction pattern of a workflow collatorinvolved in direct multi-phase communications with a client node.

FIG. 9 c illustrates a basic intra-node interaction pattern of aworkflow collator.

FIG. 9 d illustrates a relatively complex interaction pattern of aworkflow collator.

FIG. 10 illustrates the system integration of a DRM engine.

FIG. 11 illustrates an embodiment of the architecture of a DRM engine.

FIG. 12 a illustrates a DRM engine and related elements within aclient-side system node.

FIG. 12 b illustrates a DRM engine and related elements within aservice-side system node.

FIG. 13 illustrates an embodiment of content protection and governanceDRM objects.

FIG. 14 illustrates an embodiment of node and link DRM objects.

FIG. 15 illustrates an embodiment of DRM cryptographic key elements.

FIG. 16 illustrates a basic interaction pattern between client andservice-providing system nodes.

FIG. 17 a illustrates a set of notification processing nodes discoveringa node that supports a notification handler service.

FIG. 17 b illustrates the process of notification delivery.

FIG. 18 a illustrates a client-driven service discovery scenario inwhich a requesting node makes a service discovery request to a targetedservice providing node.

FIG. 18 b illustrates a peer registration service discovery scenario inwhich a requesting node seeks to register its description with a serviceproviding node.

FIG. 18 c illustrates an event-based service discovery scenario in whichan interested node receives a notification of a change in serviceavailability (e.g., the existence of a service within aservice-providing node).

FIG. 19 a illustrates the process of establishing trust using a servicebinding with an implicitly trusted channel.

FIG. 19 b illustrates the process of establishing trust based on arequest/response model.

FIG. 19 c illustrates the process of establishing trust based on anexplicit exchange of security credentials.

FIG. 20 illustrates policy-managed access to a service.

FIG. 21 illustrates a sample DRM node graph with membership and keyaccess links.

FIG. 22 illustrates an embodiment of the format of a DRM VM code module.

FIG. 23 illustrates a system function profile hierarchy.

FIG. 24 illustrates DRM music player application scenarios.

DETAILED DESCRIPTION

A detailed description of the inventive body of work is provided below.While this description is provided in conjunction with severalembodiments, it should be understood that the inventive body of work isnot limited to any one embodiment, but instead encompasses numerousalternatives, modifications, and equivalents. For example, while someembodiments are described in the context of consumer-oriented contentand applications, those skilled in the art will recognize that thedisclosed systems and methods are readily adaptable for broaderapplication. For example, without limitation, these embodiments could bereadily adapted and applied to the context of enterprise content andapplications. In addition, while numerous specific details are set forthin the following description in order to provide a thoroughunderstanding of the inventive body of work, some embodiments may bepracticed without some or all of these details. Moreover, for thepurpose of clarity, certain technical material that is known in the arthas not been described in detail in order to avoid unnecessarilyobscuring the inventive body of work.

1. Concepts

1.1. Web Services

The Web Services Architecture (WSA) is a specific instance of a ServiceOriented Architecture (SOA). An SOA is itself a type of distributedsystem consisting of loosely coupled, cooperating software agents. Theagents in an SOA may provide a service, request (consume) a service, ordo both. A service can be seen as a well-defined, self-contained set ofoperations managed by an agent acting in a service provider role. Theoperations are invoked over the network at some network-addressablelocation, called an endpoint, using standard protocols and data formats.By self-contained, it is meant that the service does not depend directlyon the state or context of another service or encompassing application.

Examples of established technologies that support the concepts of an SOAinclude CORSA, DCOM, and J2EE. WSA is attractive because it is not tiedto a specific platform, programming language, application protocolstack, or data format convention. WSA uses standard formats based on XMLfor describing services and exchanging messages which promotes loosecoupling and interoperability between providers and consumers, andsupports multiple standard Internet protocols (notably HTTP), whichfacilitates deployment and participation in a potentially globallydistributed system.

An emerging trend is to view an SOA in the context of a “plug-and-play”service bus. The service bus approach provides for orchestration ofservices by leveraging description, messaging, and transport standards.The infrastructure may also incorporate standards for discovery,transformation, security, and perhaps others as well. Through theintrinsic qualities of the ubiquitous standards incorporated into theWSA, it is flexible, extensible, and scalable, and therefore providesthe appropriate foundation for constructing an orchestrated service busmodel. In this model, the fundamental unit of work (the service) iscalled a web service.

There are a wide number of definitions for a web service. The followingdefinition comes from the World Wide Web Consortium (W3C) Web ServicesArchitecture working draft (Aug. 8, 2003—see www.w3.org/TR/ws-arch):

-   -   A Web service is a software system designed to support        interoperable machine-to-machine interaction over a network. It        has an interface described in a machine-processable format        (specifically WSDL). Other systems interact with the Web service        in a manner prescribed by its description using SOAP-messages,        typically conveyed using HTTP with an XML serialization in        conjunction with other Web-related standards.        While the W3C definition provides a useful starting point, it        should be understood that the term “web services” is used herein        in a broader sense, without limitation, for example, to the use        of specific standards, formats, and protocols (e.g., WSDL, SOAP,        XML, HTTP, etc.).

A particular web service can be described as an abstract interface for alogically coherent set of operations that provides a basis for a(possibly transient) relationship between a service provider and aservice requester.

Of course, actual web services have concrete implementations. Theprovider's concrete implementation is sometimes referred to as theservice (as distinguished from web service). The software that actuallyimplements the functionality for the service provider is the provideragent and for the service requester, the requester agent. The person ororganization that owns the agent is referred to as the provider entityor requester entity, as appropriate. When used by itself, requester orprovider may refer to either the respective entity or agent depending oncontext.

A web service exists to fulfill a purpose, and how this is achieved isspecified by the mechanics and semantics of the particular web servicemessage exchange. The mechanics refers to the precisemachine-processable technical specifications that allow the messageexchange to occur over a network. While the mechanics are preciselydefined, the semantics might not be. The semantics refers to theexplicit or implicit “contract,” in whatever form it exists, governingthe understanding and overall expectations between the requester andprovider entities for the web service.

Web services are often modeled in terms of the interactions of threeroles: (i) Service Provider; (ii) Service Requester; and (iii) ServiceRegistry. In this model, a service provider “publishes” the informationdescribing its web service to a service registry. A service requester“finds” this information via some discovery mechanism, and then usesthis information to “bind” to the service provider to utilize theservice. Binding simply means that the requester will invoke theoperations made available by the provider using the message formatting,data mapping, and transport protocol conventions specified by theprovider in the published service description. The XML-based languageused to describe this information is called Web Services DescriptionLanguage (WSDL).

A service provider offers access to some set of operations for aparticular purpose described by a WSDL service description; this servicedescription is published to a registry by any of a number of means sothat the service may be discovered. A registry may be public or privatewithin a specific domain.

A service registry is software that responds to service search requestsby returning a previously published service description. A servicerequester is software that invokes various operations offered by aprovider according to the binding information specified in the WSDLobtained from a registry.

The service registry may exist only conceptually or may in fact exist asreal software providing a database of service descriptions used toquery, locate, and bind to a particular service. But whether a requesteractually conducts an active search for a service or whether a servicedescription is statically or dynamically provided, the registry is alogically distinct aspect of the web services model. It is interestingto note that in a real world implementation, a service registry may be apart of the service requester platform, the service provider platform,or may reside at another location entirely identified by some well-knownaddress or an address supplied by some other means.

The WSDL service description supports loose coupling, often a centraltheme behind an SOA. While ultimately a service requester willunderstand the semantics of the interface of the service it is consumingfor the purpose of achieving some desired result, the servicedescription isolates a service interface from specific service bindinginformation and supports a highly dynamic web services model.

A service-oriented architecture can be built on top of many possibletechnology layers. As currently practiced, web services typicallyincorporate or involve aspects of the following technologies:

HTTP—a standard application protocol for most web servicescommunications. Although web services can be deployed over variousnetwork protocols (e.g., SMTP, FTP, etc), HTTP is the most ubiquitous,firewall-friendly transport in use. For certain applications, especiallywithin an intranet, other network protocols may make sense depending onrequirements; nevertheless, HTTP is a part of almost any web servicesplatform built today.

XML—a standard for formatting and accessing the content (and informationabout the content) of structured information. XML is a text-basedstandard for communicating information between web services agents. Notethat the use of XML does not mean that message payloads for web servicesmay not contain any binary data; but it does mean that this data will beformatted according to XML conventions. Most web services architecturesdo not necessarily dictate that messages and data be serialized to acharacter stream—they may just as likely be serialized to a binarystream where that makes sense—but if XML is being used, these streamswill represent XML documents. That is, above the level of the transportmechanism, web service messaging will often be conducted using XMLdocuments.

Two XML subset technologies that are particularly important to many webservices are XML Namespaces and XML Schema. XML-Namespaces are used toresolve naming conflicts and assert specific meanings to elementscontained with XML documents. XML-Schema are used to define andconstrain various information items contained within an XML document.Although it is possible (and optional) to accomplish these objectives byother means, the use of XML is probably the most common technique usedtoday. The XML document format descriptions for web service documentsthemselves are defined using XML-Schema, and most real world webservices operations and messages themselves will be further definedincorporating XML-Schema.

SOAP—an XML-based standard for encapsulating instructions andinformation into a specially formatted package for transmission to andhandling by other receivers. SOAP (Simple Object Access Protocol) is astandard mechanism for packaging web services messages for transmissionbetween agents. Somewhat of a misnomer, its legacy is as a means ofinvoking distributed objects and in that respect it is indeed “simpler”than other alternatives; but the recent trend is to consider SOAP as anXML-based wire protocol for purposes that have transcended the originalmeaning of the acronym.

SOAP defines a relatively lightweight convention for structuringmessages and providing information about content. Each SOAP documentcontains an envelope that is divided into a header and a body. Althoughstructurally similar, the header is generally used for meta-informationor instructions for receivers related to the handling of the contentcontained in the body.

SOAP also specifies a means of identifying features and the processingneeded to fulfill the features' obligations. A Message Exchange Pattern(MEP) is a feature that defines a pattern for how messages are exchangedbetween nodes. A common MEP is request-response, which establishes asingle, complete message transaction between a requesting and aresponding node (seehttp://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapsupmep.).

WSDL—an XML-based standard for describing how to use a web service. Froma WSDL perspective, a service is related to a set of messages exchangedbetween service requesters and providers. Messages are described in anabstract manner that can be mapped to specific protocols. The exchangeof messages that invokes some functionality is called an operation. Aspecific set of operations defines an interface. An interface is tied toa concrete message format and protocol by a named binding. The binding(the mapping of an interface to a concrete protocol) is associated witha URI appropriate to the protocol, resulting in an endpoint. Acollection of one or more related endpoints (mapping an interface toconcrete protocols at specific URIs) comprises a service.

These definitions map to specific WSDL elements:

Types container element for type definitions Message an abstractdefinition of the type of data being sent Operation an abstractdescription of an action based on a combination of input, output, andfault messages portType an abstract set of operations - an interfacebinding specification of a concrete protocol and data format for aninterface (portType) port the combination of a binding and an actualnetwork address - an endpoint service a collection of related ports(endpoints)

WSDL defines a common binding mechanism and then defines specificbinding extensions for SOAP, HTTP GET/POST, and MIME. Thus, binding doesnot necessarily mean binding to a transport protocol directly, but to aspecific wire format. The most common binding for web services is SOAP,although actual SOAP message exchanges generally occur over HTTP on port80 (via an http://URI). However, an interface can be directly bound toHTTP; alternatively, for example, a binding for SOAP can use SMTP (via amailto://URI). An implementation can even define its own wire format anduse a custom binding extension.

WSDL encourages maintainability and reusability by providing support foran <import> element. Using import, a WSDL document can be divided intoseparate pieces in ways that make sense to an organization. For acohesive web services environment desiring some degree of separationbetween an interface definition and an implementation definition, thefollowing separation into three documents is reasonable:

A schema (.xsd) document - the root node is <schema> and the namespaceis “http://www.w3.org/2001/XMLSchema.” A service interface descriptioncontaining what is considered the reusable portion <message> <portType><binding> A service implementation definition containing the specificservice end point <service>

WSDL interfaces are not exactly like Java (or IDL, or some otherprogramming language) interfaces. For example, a Java interfacedeclaration specifies a set of methods that must match at least a subsetof the methods of a class claiming to implement that interface. Morethan one class can implement an interface, and each implementation canbe different; but the method signatures (method name and any input oroutput types) generally must be identical. This is mandated by thelanguage and enforced at compile time, runtime, or both.

A WSDL interface is different, and more like an actual abstract classthat alone is not fully useful. Various WSDL interfaces, or portTypes,of a single web service are logically related in the sense that the setof operation names should be identical as if the portType did, in fact,implement a specific contract defined somewhere else but no such elementactually exists and there is no mechanism for enforcing portTypesymmetry. Each portType is generally named to identify the type ofbinding it supports even though a portType alone does not create abinding. The portType operations for related portTypes are named thesame, but the input, output, and fault messages (if present) are mappedto specific messages that contain named parts also necessary forsupporting a specific binding. This raises the point that messagesthemselves are not completely abstract. A web service may and often doesneed to define similar but distinct messages for the various bindingsrequired.

As will be illustrated below, by leveraging emerging web service andrelated standards, a system architecture can be developed thatfacilitates the creation of networked interoperable media-relatedservices that utilize a variety of different protocols and interfacesacross a wide range of hardware and software platforms and operatingenvironments.

1.2. Roles

Preferred embodiments of the present invention seek to enable, promote,and/or actively support a peer-to-peer environment in which peers canspontaneously offer a variety of functionality by exposing services. Oneembodiment of the framework discourages viewing peers as having a fixedset of capabilities; and instead encourages a model where a peer at anypoint in time is a participant in one or more roles.

A role can be defined by a set of services that a given peer exposes incombination with a specific behavior pattern. At any given moment aNEMO-enabled node may act in multiple roles based on a variety offactors: its actual implementation footprint providing the functionalityfor supporting a given set of services, administrative configuration,information declaring the service(s) the peer is capable of exposing,and load and runtime policy on service interfaces.

An explicit set of roles could be defined based on various differenttypes of services. Over time, as common patterns of participation aredetermined and as new services are introduced, a more formal rolecategorization scheme could be defined. A preliminary set of roles thatmay be formalized over time could include the following:

Client—a relatively simple role in which no services are exposed, andthe peer simply uses services of other peers.Authorizer—this role denotes a peer acting as a Policy Decision Point(PDP), determining if a requesting principal has access to a specifiedresource with a given set of pre-conditions and post-conditions.Gateway—in certain situations a peer may not be able to directlydiscover or interact with other service providers, for reasonsincluding: transport protocol incompatibility, inability to negotiate atrusted context, or lack of the processing capability to create andprocess the necessary messages associated with a given service. Agateway is a peer acting as a bridge to another peer in order to allowthe peer to interact with a service provider. From the perspective ofidentity and establishing an authorized and trusted context foroperation, the requesting peer may actually delegate to the gateway peerits identity and allow that peer to negotiate and make decisions on itsbehalf. Alternatively, the gateway peer may act as a simple relay point,forwarding or routing requests and responses.Orchestrator—in situations where interaction with a set of serviceproviders involves nontrivial coordination of services (possiblyincluding transactions, distributed state management, etc.), it may bebeyond a peer's capability to participate. An orchestrator is aspecialization of the gateway role. A peer may request an orchestratorto act on its behalf, intervening to provide one or more services. Theorchestrating peer may use certain additional NEMO components, such asan appropriately configured Workflow Collator in order to satisfy theorchestration requirements.

Given the goal of “providing instant gratification by satisfying arequest for any media, in any format, from any source, at any place, atany time, on any device complying with any agreeable set of usagerules,” the following informal model illustrates how this goal can beachieved using embodiments of the NEMO framework. It will becomeapparent from the highest level of the model (without enumerating everyaspect of how NEMO enables all of the media services that one canimagine) how NEMO enables lower-level services from different tiers inthe model to be assembled into richer end-to-end media services.

In one embodiment of this model there are four tiers of servicecomponents: 1) Content Authoring, Assembly, and Packaging services, 2)Web-based Content Aggregation and Distribution services, 3) Home Gatewayservices, and 4) Consumer Electronics devices.

Each of these four tiers typically has different requirements forsecurity, rights management, service discovery, service orchestration,user interface complexity, and other service attributes. The first twotiers fit very roughly into the models that we see for “traditional” webservices, while the last two tiers fit more into what we might call apersonal logical network model, with certain services of the homegateway being at the nexus between the two types of models. However,services for CE devices could occasionally appear in any of the tiers.

One dilemma lies in the desire to specialize parts of the framework forefficiency of implementation, while being general enough to encompass anend-to-end solution. For example, a UDDI directory and discoveryapproach may work well for relatively static and centralized webservices, but for a more dynamic transient merging of personal networks,discovery models such as those found in UPnP and Rendezvous may be moreappropriate. Thus, in some embodiments multiple discovery standards areaccommodated within the framework

Similarly, when rights management is applied to media distributionthrough wholesale, aggregator, and retail distribution sub-tiers, therecan be many different types of complex rights and obligations that needto be expressed and tracked, suggesting the need for a highly expressiveand complex rights language, sophisticated content governance andclearing services, and a global trust model. However, rights managementand content governance for the home gateway and CE device tiers mayentail a different trust model that emphasizes fair use rights that arerelatively straightforward from the consumer's point of view. Peerdevices in a personal logical network may want to interact using therelatively simple trust model of that network, and with the ability tointeract with peers across a wide area network using a global trustmodel, perhaps through proxy gateway services. At the consumer end,complexity arises from automated management of content availabilityacross devices, some of which are mobile and intermittently intersectmultiple networks. Thus, an effective approach to rights management,while enabling end-to-end distribution, might also be heterogeneous,supporting a variety of rights management services, including servicesthat interpret expressions of distribution rights and translate them, incontext, to individual consumer use rights in a transaction that isorchestrated with a sales transaction, or perhaps another event where asubscription right is exercised.

1.3. Logical Model

In one embodiment, the system framework consists of a logicallyconnected set of nodes that interact in a peer-to-peer (P2P) fashion.Peer-to-peer computing is often defined as the sharing of resources(such as hard drives and processing cycles) among computers and otherintelligent devices. See http://www.intel.com/cure/peer.htm. Here, P2Pmay be viewed as a communication model allowing network nodes tosymmetrically consume and provide services of all sorts. P2P messagingand workflow collation allow rich services to be dynamically createdfrom a heterogeneous set of more primitive services. This enablesexamination of the possibilities of P2P computing when the sharedresources are services of many different types, even using differentservice bindings.

Different embodiments can provide a media services framework enablingstakeholders (e.g., consumers, content providers, device manufacturers,and service providers) to find one another, to interact, exchange value,and to cooperate in rich and dynamic ways. These different types ofservices range from the basic (discovery, notification, search, and filesharing) to more complex higher level services (such as lockers,licensing, matching, authorization, payment transaction, and update),and combinations of any or all of these.

Services can be distributed across peer-to-peer communicating nodes,each providing message routing and orchestration using a message pumpand workflow collator (described in greater detail below) designed forthis framework.

Nodes interact by making service invocation requests and receivingresponses. The format and payload of the request and response messagesare preferably defined in a standard XML schema-based web servicedescription language (e.g., WSDL) that embodies an extensible set ofdata types enabling the description and composition of services andtheir associated interface bindings. Many of the object types in WSDLare polymorphic and can be extended to support new functionality. Thesystem framework supports the construction of diverse communicationpatterns, ranging from direct interaction with a single service providerto a complex aggregation of a choreographed set of services frommultiple service providers. In one embodiment, the framework supportsthe basic mechanisms for using existing service choreography standards(WSCI, BPEL, etc.), and also allows service providers to use their ownconventions.

The syntax of messages associated with service invocation are preferablydescribed in a relatively flexible and portable manner, as are the coredata types used within the system framework. In one embodiment, this isaccomplished using WSDL to provide relatively simple ways forreferencing semantic descriptions associated with described services.

A service interface may have one or more service bindings. In such anembodiment, a node may invoke the interface of another node as long asthat node's interface binding can be expressed in, e.g., WSDL, and aslong as the requesting node can support the conventions and protocolsassociated with the binding. For example, if a node supports a webservice interface, a requesting node may be required to support SOAP,HTTP, WS-Security, etc.

Any service interface may be controlled (e.g., rights managed) in astandardized fashion directly providing aspects of rights management.Interactions between nodes can be viewed as governed operations.

Virtually any type of device (physical or virtual) can be viewed aspotentially NEMO-enabled, and able to implement key aspects of the NEMOframework. Device types include, for example, consumer electronicsequipment, networked services, and software clients. In a preferredembodiment, a NEMO-enabled device (node) typically includes some or allof the following logical modules (discussed in greater detail below):

Native Services API—the set of one or more services that the deviceimplements. There is no requirement that a NEMO node expose any servicedirectly or indirectly in the NEMO framework.Native Service Implementation—the corresponding set of implementationsfor the native services API.Service Adaptation Layer—the logical layer through which an exposedsubset of an entity's native services is accessed using one or morediscoverable bindings described in, e.g., WSDL.Framework Support Library—components that provide support functionalityfor working with the NEMO Framework including support for invokingservice interfaces, message processing, service orchestration, etc.

1.4. Terminology

In one embodiment, a basic WSDL profile defines a minimum “core” set ofdata types and messages for supporting interaction patterns andinfrastructural functionality. Users may either directly, in an ad-hocmanner, or through some form of standardization process, define otherprofiles built on top of this core, adding new data and service typesand extending existing ones. In one embodiment, this core profileincludes definitions for some or all of the following major basic datatypes:

Node—a representation of a participant in the system framework. A nodemay act in multiple roles including that of a service consumer and/or aservice provider. Nodes may be implemented in a variety of formsincluding consumer electronic devices, software agents such as mediaplayers, or virtual service providers such as content search engines,DRM license providers, or content lockers.Device—encapsulates the representation of a virtual or physical device.User—encapsulates the representation of a client user.Request—encapsulates a request for a service to a set of targeted Nodes.Request Input—encapsulates the input for a Request.Response—encapsulates a Response associated with a Request.Request Result—encapsulates the Results within a Response associatedwith some Request.Service—encapsulates the representation of a set of well-definedfunctionality exposed or offered by a provider Node. This could be, forexample, low-level functionality offered within a device such as a cellphone (e.g. a voice recognition service), or multi-faceted functionalityoffered over the world-wide web (e.g. a shopping service). Servicescould cover a wide variety of applications, including DRM-relatedservices such as client personalization and license acquisition.Service Provider—an entity (e.g., a Node or Device) that exposes someset of Services. Potential Service Providers include consumerelectronics devices, such as cell phones, PDAs, portable media playersand home gateways, as well as network operators (such as cablehead-ends), cellular network providers, web-based retailers and contentlicense providers.Service Interface—a well-defined way of interacting with one or moreServices.Service Binding—encapsulates a specific way to communicate with aService, including the conventions and protocols used to invoke aService Interface. These may be represented in a variety of well-definedways, such as the WS-I standard XML protocol, RPC based on the WSDLdefinition, or a function invocation from a DLL.Service Access Point (SAP)—encapsulates the functionality necessary forallowing a Node to make a Service Invocation Request to a targeted setof Service Providing Nodes, and receive a set of Responses.Workflow Collator (WFC)—a Service Orchestration mechanism that providesa common interface allowing a Node to manage and process collections ofRequests and Responses related to Service invocations. This interfaceprovides the basic building blocks to orchestrate Services throughmanagement of the Messages associated with the Services.

In the context of a particular application, such as digital rightsmanagement (DRM), a typical profile might include various DRM-relatedservices (described below) for the following set of content protectionand governance objects, which represent entities in the system, protectcontent, associate usage rules with the content, and determine if accesscan be granted when requested:

Content Reference—encapsulates the representation of a reference orpointer to a content item. Such a reference will typically leverageother standardized ways of describing content format, location, etc.DRM Reference—encapsulates the representation of a reference or pointerto a description of a digital rights management format.Link—links between entities (e.g., Nodes).Content—represents media or other content.Content Key—represents encryption keys used to encrypt Content.Control—represents usage or other rules that govern interaction withContent.Controller—represent associations between Control and ContentKey objectsProjector—represent associations between Content and ContentKey objects

In one embodiment, a core profile includes definitions for some or allof the following basic Services:

Authorization—a request or response to authorize some participant toaccess a Service.Governance—The process of exercising authoritative or dominatinginfluence over some item (e.g., a music file, a document, or a Serviceoperation), such as the ability to download and install a softwareupgrade. Governance typically interacts with Services providingfunctionality such as trust management, policy management, and contentprotection.Message Routing—a Request or Response to provide message routingfunctionality, including the ability to have the Service Providing Nodeforward the message or collect and assemble messages.Node Registration—a Request or Response to perform registrationoperations for a Node, thereby allowing the Node to be discoveredthrough an Intermediate Node.Node Discovery (Query)—a Request or Response related to the discovery ofNodes.Notification—a Request or Response to send or deliver targetedNotification messages to a given set of Nodes.Security Credential Exchange—a Request or Response related to allowingNodes to exchange security related information, such as key pairs,certificates, or the like.Service Discovery (Query)—a Request or Response related to the discoveryof Services provided by some set of one or more Nodes.Service Orchestration—The assembly and coordination of Services intomanageable, coarser-grained Services, reusable components, or fullapplications that adhere to rules specified by a service provider.Examples include rules based on provider identity, type of Service,method by which Services are accessed, order in which Services arecomposed, etc.Trust Management—provides a common set of conventions and protocols forcreating authorized and trusted contexts for interactions between Nodes.In some embodiments, NEMO Trust Management may leverage and/or extendexisting security specifications and mechanisms, including WS-Securityand WS-Policy in the web services domain.Upgrade—represents a Request or Response related to receiving afunctionality upgrade.In one embodiment, this service is purely abstract, with other profilesproviding concrete representations.

1.5. Illustrative Interaction Between Nodes

As will be discussed in greater detail below, the basic logicalinteraction between two system nodes, a service requester and a serviceprovider, typically includes the following sequence of events. From theperspective of the service requesting node:

The service requesting node makes a service discovery request to locateany NEMO-enabled nodes that can provide the necessary service using thespecified service bindings. A node may choose to cache information aboutdiscovered services. The interface/mechanism for service discoverybetween nodes can be just another service that a NEMO node chooses toimplement.

Once candidate service providing nodes are found, the requesting nodemay choose to dispatch a request to one or more of the service providingnodes based on a specific service binding.

In one embodiment, two nodes that wish to communicate securely with eachother will establish a trusted relationship for the purpose ofexchanging WSDL messages. For example, they may negotiate a set ofcompatible trust credentials (e.g., X.500 certificates, device keys,etc.) that may be used in determining identity, verifying authorization,establishing a secure channel, etc. In some cases, the negotiation ofthese credentials may be an implicit property of the service interfacebinding (e.g., WS-Security if WS-I XML Protocol is used, or an SSLrequest between two well-known nodes). In other cases, the negotiationof trust credentials may be an explicitly separate step. In oneembodiment, it is up to a given node to determine which credentials aresufficient for interacting with another node, and to make the decisionthat it can trust a given node.

The requesting node creates the appropriate WSDL request message(s) thatcorrespond to the requested service.

Once the messages are created, they are dispatched to the targetedservice providing node(s). The communication style of the request may,for example, be synchronous or asynchronous RPC style, ormessage-oriented based on the service binding. Dispatching of servicerequests and receiving of responses may be done directly by the deviceor through the NEMO Service Proxy. The service proxy (described below)provides an abstraction and interface for sending messages to otherparticipants, and may hide certain service binding issues, such ascompatible message formats, transport mechanisms, message routingissues, etc.

After dispatching a request, the requesting node will typically receiveone or more responses. Depending on the specifics of the serviceinterface binding and the requesting node's preferences, the response(s)may be returned in a variety of ways, including, for example, anRPC-style response or a notification message. The response, en-route tothe targeted node(s), may pass through other intermediate nodes that mayprovide a number of relevant services, including, e.g., routing, trustnegotiation, collation and correlation functions, etc.

The requesting node validates the response(s) to ensure it adheres tothe negotiated trust semantics between it and the service providingnode.

Appropriate processing is then applied based on the message payload typeand contents.

From the perspective of the service providing node, the sequence ofevents typically would include the following:

Determine if the requested service is supported. In one embodiment, theNEMO framework does not mandate the style or granularity of how aservice interface maps as an entry point to a service. In the simplestcase, a service interface may map unambiguously to a given service andthe act of binding to and invoking it may constitute support for theservice. However, in some embodiments a single service interface mayhandle multiple types of requests; and a given service type may containadditional attributes that need to be examined before a determinationcan be made that the node supports the specifically desiredfunctionality.

In some cases it may be necessary for the service provider to determineif it trusts the requesting node and to negotiate a set of compatibletrust credentials. In one embodiment, regardless of whether the serviceprovider determines trust, any policy associated with the serviceinterface will still apply.

The service provider determines and dispatches authorization request(s)to those node(s) responsible for authorizing access to the interface inorder to determine if the requesting node has access. In manysituations, the authorizing node and the service providing node will bethe same entity, and the dispatching and processing of the authorizationrequest will be local operations invoked through a lightweight serviceinterface binding such as a C function entry point.

Upon receiving the authorization response, if the requesting node isauthorized, the service provider will fulfill the request. If not, anappropriate response message might be generated.

The response message is returned based on the service interface bindingand requesting node's preferences. En route to the requesting node, themessage may pass through other intermediate nodes that may providenecessary or “value added” services. For example an intermediate nodemight provide routing, trust negotiation, or delivery to a notificationprocessing node that can deliver the message in a way acceptable' to therequesting node. An example of a “value added” service is a couponservice that appends coupons to the message if it knows of therequesting node's interests.

2. System Architecture

Consider a sample embodiment of the NEMO system framework, asillustrated in FIG. 1, implementing a DRM application.

As noted above, NEMO nodes may interact by making service invocationrequests and receiving responses. The NEMO framework supports theconstruction of diverse and rich communication patterns ranging from asimple point to point interaction with a single service provider to acomplex aggregation of a choreographed set of services from multipleservice providers.

In the context of FIG. 1, the NEMO nodes interact with one another toprovide a variety of services that, in the aggregate, implement a musiclicensing system. Music stored in Consumer Music Locker 110 can beextracted by Web Music Retailer 120 and provided to end users at theirhomes via their Entertainment Home Gateway 130. Music from ConsumerMusic Locker 110 may include rules that govern the conditions underwhich such music may be provided to Web Music Retailer 120, andsubsequently to others for further use and distribution. EntertainmentHome Gateway 130 is the vehicle by which such music (as well as videoand other content) can be played, for example, on a user's home PC(e.g., via PC Software Video Player 140) or on a user's portableplayback device (e.g., Portable Music Player 150). A user might travel,for example, with Portable Music Player 150 and obtain, via a wirelessInternet connection (e.g., to Digital Rights License Service 160), alicense to purchase additional songs or replay existing songs additionaltimes, or even add new features to Portable Music Player 150 viaSoftware Upgrade Service 170.

NEMO nodes can interact with one another, and with other devices, in avariety of different ways. A NEMO host, as illustrated in FIG. 2 a, issome type of machine or device hosting at least one NEMO node. A hostmay reside within a personal area network 210 or at a remote location220 accessible via the Internet. A host could, for example, be a server230, a desktop PC 240, a laptop 250, or a personal digital assistant260.

A NEMO node is a software agent that can provide services to other nodes(such as host 235 providing a 3^(rd) party web service) as well asinvoke other nodes' services within the NEMO-managed framework. Somenodes 270 are tethered to another host via a dedicated communicationchannel, such as Bluetooth. These hosts 240 and 250 are equipped withnetwork connectivity and sufficient processing power to present avirtual node to other participating NEMO nodes.

As illustrated in FIG. 2 b, a NEMO node can be a full peer within thelocal or personal area network 210. Nodes share the symmetric capabilityof exposing and invoking services; however, each node generally does notoffer identical sets of services. Nodes may advertise and/or bespecifically queried about the services they perform.

If an Internet connection is present, as shown in FIG. 2 c, then localNEMO nodes (e.g., within personal area network 210) can also access theservices of remote nodes 220. Depending on local network configurationand policy, it is also possible for local and remote nodes (e.g.,Internet-capable NEMO hosts 280) to interoperate as NEMO peers.

As illustrated in FIG. 2 d, not all NEMO nodes may be on hosts capableof communicating with other hosts, whether local or remote. A NEMO host280 can provide a gateway service through which one node can invoke theservices of another, such as tethered node 285 or nodes in personal areanetwork 210.

As illustrated in FIG. 2 e, a node 295 on a tethered device may accessthe services of other nodes via a gateway, as discussed above. It mayalso be accessed by other nodes via a proxy service on another host 290.The proxy service creates a virtual node running on the NEMO host. Theseproxy nodes can be full NEMO peers.

As illustrated in FIG. 2 f, a NEMO host may provide dedicated supportfor tethered devices via NEMO node adapters. A private communicationchannel 296 is used between host/NEMO device adapter 297 and tetherednode 298 using any suitable protocol. Tethered node 298 does not see,nor is it visible to, other NEMO peer nodes.

We next consider exemplary digital rights management (DRM) functionalitythat can be provided by NEMO-enabled devices in certain embodiments, orthat can be used outside the NEMO context. As previously described, oneof the primary goals of a preferred embodiment of the NEMO systemframework is to support the development of secure, interoperableinterconnections between media-related services spanning both commercialand consumer-oriented network tiers. In addition to serviceconnectivity, interoperability between media-related services will oftenrequire coordinated management of usage rights as applied to the contentavailable through those services. NEMO services and the exemplary DRMengine described herein can be used in combination to achieveinteroperability that allows devices based on the NEMO framework toprovide consumers with the perception of a seamless rendering and usageexperience, even in the face of a heterogeneous DRM and media formatinfrastructure.

In the context of a DRM application, as illustrated in FIG. 3, a networkof NEMO-enabled DRM devices may include content provider/server 310,which packages content for other DRM devices, as well as consumer PCplayer 330 and consumer PC packager/player 320, which can not only playprotected content, but can also package content for delivery to portabledevice 340.

Within each DRM device, the DRM engine performs specific DRM functions(e.g., enforcing license terms, delivering keys to the host application,etc.), and relies on the host application for those services which canbe most effectively provided by the host, such as encryption,decryption, and file management.

As will be discussed in greater detail below, in one embodiment the DRMengine includes a virtual machine (VM) designed to determine whethercertain actions on protected content are permissible. This Control VMcan be implemented as a simple stack-based machine with a minimal set ofinstructions. In one embodiment, it is capable of performing logical andarithmetic calculations, as well as querying state information from thehost environment to check parameters such as system time, counter state,and so forth.

In one embodiment, the DRM engine utilizes a graph-based algorithm toverify relationships between entities in a DRM value chain. FIG. 4illustrates a conceptual embodiment of such a graph. The graph comprisesa collection of nodes or vertices, connected by links. Each entity inthe system can be represented by a vertex object. Only entities thatneed to be referenced by link objects, or be the recipient ofcryptographically targeted information, need to have correspondingvertex objects. In one embodiment, a vertex typically represents a user,a device, or a group. Vertex objects also have associated attributesthat represent certain properties of the entity associated with thevertex.

For example, FIG. 4 shows two users (Xan and Knox), two devices (the Macand a portable device), and several entities representing groups(members of the Carey family, members of the public library, subscribersto a particular music service, RIAA-approved devices, and devicesmanufactured by a specific company). Each of these has a vertex objectassociated with it.

The semantics of the links may vary in an application-specific manner.For example, the directed edge from the Mac vertex to the Knox vertexmay mean that Knox is the owner of the Mac. The edge from Knox to PublicLibrary may indicate that Knox is a member of the Public Library. In oneembodiment the DRM engine does not impose or interpret thesesemantics—it simply ascertains the existence or non-existence of pathswithin the graph. This graph of vertices can be considered an“authorization” graph in that the existence of a path or relationship(direct or indirect) between two vertices may be interpreted as anauthorization for one vertex to access another vertex.

For example, because Knox is linked to the Carey family and the Careyfamily is linked to the Music Service, there is a path between Knox andthe Music Service. The Music Service vertex is considered reachable fromanother vertex when there is a path from that vertex to the MusicService. This allows a control to be written that allows permission toaccess protected content based on the condition that the Music Servicebe reachable from the portable device in which the application thatrequests access (e.g., a DRM client host application) is executing.

For example, a content owner may create a control program to beinterpreted by the Control VM that allows a particular piece of music tobe played if the consuming device is owned by a member of the PublicLibrary and is RIAA-approved. When the Control VM running on the deviceevaluates this control program, the DRM engine determines whether linksexist between Portable Device and Public Library, and between PortableDevice and RIAA Approved. The edges and vertices of the graph may bestatic and built into devices, or may be dynamic and discovered throughservices communicating with the host application.

By not imposing semantics on the vertices and links, the DRM engine canenable great flexibility. The system can be adapted to many usagemodels, from traditional delegation-based policy systems to authorizeddomains and personal area networks.

In one embodiment, the DRM client can also reuse the authorization graphfor content protection key derivation. System designers may chose toallow the existence of a link to also indicate the sharing of certaincryptographic information. In such cases, the authorization graph can beused to derive content keys without explicit cryptographic retargetingto consuming devices.

3. Node Architecture

3.1. Overview

Any type of device (physical or virtual), including consumer electronicsequipment, networked services, or software clients, can potentially beNEMO-enabled, which means that the device's functionality may beextended in such a way as to enable participation in the NEMO system. Inone embodiment, a NEMO-enabled device (node) is conceptually comprisedof certain standard modules, as illustrated in FIG. 5 a.

Native Services API 510 represents the logical set of one or moreservices that the device implements. There is no requirement that a NEMOnode expose any service directly or indirectly. Native ServiceImplementation 520 represents the corresponding set of implementationsfor the native services API.

Service Access Point 530 provides support for invoking exposed serviceinterfaces. It encapsulates the functionality necessary for allowing aNEMO node to make a service invocation request to a targeted set ofservice-providing NEMO nodes and to receive a set of responses.NEMO-enabled nodes may use diverse discovery, name resolution, andtransport protocols, necessitating the creation of a flexible andextensible communication API. The Service Access Point can be realizedin a variety of ways tailored to a particular execution environment andapplication framework style. One common generic model for its interfacewill be an interface capable of receiving XML messages in some form andreturning XML messages. Other models with more native interfaces canalso be supported.

NEMO Service Adaptation Layer 540 represents an optional layer throughwhich an exposed subset of an entity's native services are accessedusing one or more discoverable bindings. It provides a level ofabstraction above the native services API, enabling a service providerto more easily support multiple types of service interface bindings. Insituations where a service adaptation layer is not present, it may stillbe possible to interact with the service directly through the ServiceAccess Point 530 if it supports the necessary communication protocols.

The Service Adaptation Layer 540 provides a common way for serviceproviders to expose services, process requests and responses, andorchestrate services in the NEMO framework. It is the logical point atwhich services are published, and provides a foundation on which toimplement other specific service interface bindings.

In addition to providing a common way of exposing a service provider'snative services to other NEMO-enabled nodes, Service Adaptation Layer540 also provides a natural place on which to layer components forsupporting additional service interface bindings 560, as illustrated inFIG. 5 b. By supporting additional service interface bindings, a serviceprovider increases the likelihood that a compatible binding will be ableto be negotiated and used either by a Service Access Point or throughsome other native API.

Referring back to FIG. 5 a, Workflow Collator 550 provides supportingmanagement of service messages and service orchestration. It provides acommon interface allowing a node to manage and process collections ofrequest and response messages. This interface in turn provides the basicbuilding blocks to orchestrate services through management of themessages associated with those services. This interface typically isimplemented by a node that supports message routing functionality aswell as the intermediate queuing and collating of messages.

In some embodiments, the NEMO framework includes a collection ofoptional support services that facilitate an entity's participation inthe network. Such services can be classified according to various typesof functionality, as well as the types of entities requiring suchservices (e.g., services supporting client applications, as opposed tothose needed by service providers). Typical supporting services includethe following:

WSDL Formatting and Manipulation Routines—provide functionality for thecreation and manipulation of WSDL-based service messages.Service Cache—provides a common interface allowing a node to manage acollection of mappings between discovered nodes and the services theysupport.Notification Processor Interface—provides a common service providerinterface for extending a NEMO node that supports notificationprocessing to some well-defined notification processing engine.Miscellaneous Support Functionality—including routines for generatingmessage IDs, timestamps, etc.

3.2. Basic Node Interaction

Before examining the individual architectural elements of NEMO nodes ingreater detail, it is helpful to understand the manner by which suchnodes interact and communicate with one another. Diverse communicationstyles are supported, ranging from synchronous and asynchronousRPC-style communication, to one-way interface invocations and clientcallbacks.

Asynchronous RPC Delivery Style—this model is particularly appropriateif there is an expectation that fulfilling the request will take anextended period of time and the client does not want to wait. The clientsubmits a request with the expectation that it will be processed in anasynchronous manner by any service-providing nodes. In this case, theservice-providing endpoint may respond indicating that it does notsupport this model, or, if the service-providing node does support thismodel, it will return a response that will carry a ticket that can besubmitted to the given service-providing node in subsequent requests todetermine if it has a response to the client's request.

In one embodiment, any service-providing endpoint that does support thismodel is obligated to cache responses to pending client requests basedon an internal policy. If a client attempts to redeem a ticketassociated with such a request and no response is available, or theresponse has been thrown away by the service-providing node, then anappropriate error response is returned. In this embodiment, it is up tothe client to determine when it will make such follow-on requests inattempting to redeem the ticket for responses.

Synchronous RPC Delivery Style—the client submits a request and thenwaits for one or more responses to be returned. A service-providingNEMO-enabled endpoint may respond indicating that it does not supportthis model.

Message-Based Delivery Style—the client submits a request indicatingthat it wants to receive any responses via a message notificationassociated with one or more of its notification handling serviceinterfaces. A service-providing NEMO-enabled endpoint may respondindicating that it does not support this model.

From the client application's perspective, none of the interactionpatterns above necessitates an architecture that must block and wait forresponses, or must explicitly poll. It is possible to use threading orother platform-specific mechanisms to model both blocking andnon-blocking semantics with the above delivery style mechanisms. Also,none of the above styles is intended to directly address issuesassociated with the latency of a given communication channel—onlypotential latency associated with the actual fulfillment of a request.Mechanisms to deal with the issues associated with communication channellatency should be addressed in the specific implementation of acomponent such as the Service Access Point, or within the client'simplementation directly.

3.3. Service Access Point

As noted above, a Service Access Point (SAP) can be used as a common,reusable API for service invocation. It can encapsulate the negotiationand use of a transport channel. For example, some transport channels mayrequire SSL session setup over TCP/IP, while some channels may onlysupport relatively unreliable communication over UDP/IP, and stillothers may not be IP-based at all.

A SAP can encapsulate the discovery of an initial set of NEMO nodes formessage routing. For example, a cable set-top box may have a dedicatedconnection to the network and mandate that all messages flow through aspecific route and intermediary. A portable media player in a homenetwork may use UPnP discovery to find multiple nodes that are directlyaccessible. Clients may not be able, or may choose not, to conversedirectly with other NEMO nodes by exchanging XML messages. In this case,a version of the SAP may be used that exposes and uses whatever nativeinterface is supported.

In a preferred embodiment, the SAP pattern supports the following twocommon communication models (although combinations of the two, as wellas others, may be supported): (i) Message Based (as discussedabove)—where the SAP forms XML request messages and directly exchangesNEMO messages with the service provider via some interface binding; or(ii) Native—where the SAP may interact with the service provider throughsome native communication protocol. The SAP may internally translateto/from XML messages defined elsewhere within the framework.

A sample interaction between two NEMO peer nodes is illustrated in FIG.6 a. Client node 610 interacts with service-providing node 660 usingNEMO service access point (SAP) 620. In this example, web serviceprotocols and standards are used both for exposing services and fortransport. Service-providing node 660 uses its web services layer 670(using, e.g., WSDL and SOAP-based messaging) to expose its services toclients such as node 610. Web services layer 630 of client node 610creates and interprets SOAP messages, with help from mapping layer 640(which maps SOAP messages to and from SAP interface 620) and trustmanagement processing layer 650 (which could, for example, leverageWS-Security using credentials conveyed within SOAP headers).

Another example interaction between NEMO nodes is illustrated in FIG. 6b. Service-providing node 682 interacts with client node 684 using SAP686. In this example, service-providing node 682 includes a differentbut interoperable trust management layer than client 684. In particular,service-providing node 682 includes both a trust engine 688 and anauthorization engine 690. In this example, trust engine 688 might begenerally responsible for performing encryption and decryption of SOAPmessages, for verifying digital certificates, and for performing otherbasic cryptographic operations, while authorization engine 690 might beresponsible for making higher-level policy decisions. In the exampleshown in FIG. 6 b, client node 684 includes a trust engine 692, but notan authorization engine. Thus, in this example, client node 684 might becapable of performing basic cryptographic operations and enforcingrelatively simple policies (e.g., policies related to the level ofmessage authenticity, confidentiality, or the like), but might rely onservice providing node 682 to evaluate and enforce higher order policiesgoverning the client's use of, and interaction with, the services and/orcontent provided by service providing node 682. It should be appreciatedthat FIG. 6 b is provided for purposes of illustration and notlimitation, and that in other embodiments client node 684 might alsoinclude an authorization engine, as might be the case if the clientneeded to adhere to a set of obligations related to a specified policy.Thus, it can be seen that different NEMO peers can contain differentparts of the trust management framework depending on their requirements.FIG. 6 b also illustrates that the communication link between nodes canbe transport agnostic. Even in the context of a SOAP processing model,any suitable encoding of data and/or processing rules can be used. Forexample, the XML security model could be replaced with another securitymodel that supported a different encoding scheme.

A Service Access Point may be implemented in a variety of forms, such aswithin the boundaries of a client (in the form of a shared library) oroutside the boundaries of the client (in the form of an agent running ina different process). The exact form of the Service Access Pointimplementation can be tailored to the needs of a specific type ofplatform or client. From a client's perspective, use of the ServiceAccess Point may be optional, although in general it providessignificant utility, as illustrated below.

The Service Access Point may be implemented as a static componentsupporting only a fixed set of service protocol bindings, or it may beable to support new bindings dynamically.

Interactions involving the Service Access Point can be characterizedfrom at least two perspectives—a client-side which the requestingparticipant uses, and a service-side which interacts with otherNEMO-enabled endpoints (nodes).

In one client-side embodiment, illustrated in FIG. 7 a, Service AccessPoint 710 directly exchanges XML messages with client 720. Client 720forms request messages 740 directly and submits them to Service AccessPoint 710, which generates and sends one or more response messages 750to client 720, where they are collected, parsed and processed. Client720 may also submit (when making requests) explicit set(s) of servicebindings 730 to use in targeting the delivery of the request. Theseservice bindings may have been obtained in a variety of ways. Forexample, client 720 can perform service-discovery operations and thenselect which service bindings are applicable, or it can use informationobtained from previous responses.

In another client-side embodiment, illustrated in FIG. 7 b, ServiceAccess Point 760 directly supports a native protocol 770 of client 780.Service Access Point 760 will translate messages internally between XMLand that native protocol 770, thereby enabling client 780 to participatewithin the NEMO system. To effect such support, native protocol 770 (ora combination of native protocol 770 and the execution environment) mustprovide any needed information in some form to Service Access Point 760,which generates an appropriate request and, if necessary, determines asuitable target service binding.

On the service-side, multiple patterns of interaction between a client'sService Access Point and service-providing NEMO-enabled endpoints can besupported. As with the client-side, the interaction patterns can betailored and may vary based on a variety of criteria, including thenature of the request, the underlying communication network, and thenature of the application and/or transport protocols associated with anytargeted service bindings.

A relatively simple type of service-side interaction pattern isillustrated in FIG. 7 c, in which Service Access Point 711 communicatesdirectly with the desired service-providing node 712 in a point-to-pointmanner.

Turning to FIG. 7 d, Service Access Point 721 may initiate communicationdirectly with (and may receive responses directly from) multiplepotential service providers 725. This type of interaction pattern may beimplemented by relaying multiple service bindings from the client foruse by Service Access Point 721; or a broadcast or multicast networkcould be utilized by Service Access Point 721 to relay messages. Basedon preferences specified in the request, Service Access Point 721 maychoose to collect and collate responses, or simply return the firstacceptable response.

In FIG. 7 e, Service Access Point 731 doesn't directly communicate withany targeted service-providing endpoints 735. Instead, requests arerouted through an intermediate node 733 which relays the request,receives any responses, and relays them back to Service Access Point731.

Such a pattern of interaction may be desirable if Service Access Point731 is unable or unwilling to support directly any of the servicebindings associated with service-providing endpoints 735, but canestablish a relationship with intermediate node 733, which is willing toact as a gateway. Alternatively, the client may not be able to discoveror otherwise determine the service bindings for any suitableservice-providing nodes, but may be willing to allow intermediate node733 to attempt to discover any suitable service providers. Finally,Service Access Point 731 may want to take advantage of intermediate node733 because it supports more robust collection and collatingfunctionality, which in turn permits more flexible communicationpatterns between Service Access Point 731 and service providers such asendpoint nodes 735.

In addition to the above basic service-side interaction patterns,combinations of such patterns or new patterns can be implemented withinthe Service Access Point. Although the Service Access Point is intendedto provide a common interface, its implementation will typically bestrongly tied to the characteristics of the communication models andassociated protocols employed by given NEMO-enabled endpoints.

In practice, the Service Access Point can be used to encapsulate thelogic for handling the marshalling and un-marshaling of I/O relateddata, such as serializing objects to appropriate representations, suchas an XML representation (with a format expressed in WSDL), or one thatenvelopes XML-encoded objects in the proper format.

In a preferred embodiment, the SAP also encapsulates logic forcommunication via one or more supported application, session, and/ortransport protocols, such as service invocation over HTTP using SOAPenveloping.

Finally, in some embodiments, the SAP may encapsulate logic forproviding message integrity and confidentiality, such as support forestablishing SSL/TLS sessions and/or signing/verifying data viastandards such as XML-Signature and XML-Encryption. When the specificaddress of a service interface is unknown or unspecified (for example,when invoking a service across multiple nodes based on some searchcriteria), the SAP may encapsulate the logic for establishing an initialconnection to a default/initial set of NEMO nodes where services can bediscovered or resolved.

The following is an example, non-limiting embodiment of a high-level APIdescription exported by one SAP embodiment:

ServiceAccessPoint::Create(Environment[ ])→ServiceAccessPoint—this is asingleton interface that returns an initialized instance of a SAP. TheSAP can be initialized based on an optional set of environmentalparameters.ServiceAccessPoint::InvokeService(Service Request Message,Boolean)→Service Response Message—a synchronous service invocation APIis supported where the client (using WSDL) forms an XML service requestmessage, and receives an XML message in response. The API also accept aBoolean flag indicating whether or not the client should wait for aresponse. Normally, the flag will be true, except in the case ofmessages with no associated response, or messages to which responseswill be delivered back asynchronously via another channel (such as vianotification). The resulting message may also convey some resultingerror condition.ServiceAccessPoint::ApplyIntegrityProtection(Boolean, Desc[])→Boolean—This API allows the caller to specify whether integrityprotection should be applied, and to which elements in a message itshould be applied.ServiceAccessPoint::ApplyConfidentiality(Boolean, Descp [])→Boolean—This API allows the caller to specify whether confidentialityshould be applied and to which objects in a message it should beapplied.

ServiceAccessPoint::SetKeyCallbacks( SigningKeyCallback,SignatureVerificationKeyCallback, EncryptionKeyCallback,DecryptionKeyCallback) → BooleanAs indicated in the previous APIs, when a message is sent or received itmay contain objects which require integrity protection orconfidentiality. This API allows the client to set up any necessaryhooks between itself and the SAP to allow the SAP to obtain keysassociated with a particular type of trust management operation. In oneembodiment, the interface is based on callbacks supporting integrityprotection through digital signing and verification, and confidentialitythrough encryption and decryption. In one embodiment, each of thecallbacks is of the form:

KeyCallback(KeyDesc)→Key[ ]

where KeyDesc is an optional object describing the key(s) required and alist of appropriate keys is returned. Signatures are validated as partof receiving response services messages when using the InvokeService( .. . ) API. If a message element fails verification, an XML message canbe returned from InvokeService( . . . ) indicating this state and theelements that failed verification.

3.4. Service Adaptation Layer

As noted above, the Service Adaptation Layer provides a common way forservice providers to expose their services, process requests andgenerate responses for services, and orchestrate services in the NEMOframework. It also provides a foundation on which other specific serviceinterface bindings can be implemented. In one embodiment, WSDL is usedto describe a service's interface within the system.

Such a service description might, in addition to defining how to bind toa service on a particular interface, also include a list of one or moreauthorization service providers that will be responsible for authorizingaccess to the service, a pointer to a semantic description of thepurpose and usage of the service, and a description of the necessaryorchestration for composite services resulting from the choreographedexecution of one or more other services.

In addition to serving as the logical point at which services areexposed, the Service Adaptation Layer also preferably encapsulates theconcrete representations of the NEMO data types and objects specified inNEMO service profiles for platforms that are supported by a givenparticipant. It also contains a mechanism for mapping service-relatedmessages to the appropriate native service implementation.

In one embodiment, the NEMO framework does not mandate how the ServiceAdaptation Layer for a given platform or participant is realized. Insituations where a service-providing node does not require translationof its native service protocols i.e., exposing its services only toclient nodes that can communicate via that native protocol then thatservice-providing node need not contain a Service Adaptation Layer.

Otherwise, its Service Adaptation Layer will typically contain thefollowing elements, as illustrated in FIG. 8:

Entry Points—a layer encapsulating the service interface entry points810 and associated WSDL bindings. Through these access points, othernodes invoke services, pass parameter data, and collect results.Message Processing Logic—a layer 820 that corresponds to the logic formessage processing, typically containing a message pump 825 that drivesthe processing of messages, some type of XML data binding support 826,and low level XML parser and data representation support 827.Native Services—a layer representing the native services available (ontowhich the corresponding service messages are mapped), including a nativeservices API 830 and corresponding implementation 840.

3.5. Workflow Collator

In a preferred embodiment, a Workflow Collator (WFC) helps fulfill mostnontrivial NEMO service requests by coordinating the flow of events of arequest, managing any associated data including transient andintermediate results, and enforcing the rules associated withfulfillment. Examples of this type of functionality can be seen in theform of transaction coordinators ranging from simple transactionmonitors in relational databases to more generalized monitors as seen inMicrosoft MTS/COM+.

In one embodiment, the Workflow Collator is a programmable mechanismthrough which NEMO nodes orchestrate the processing and fulfillment ofservice invocations. The WFC can be tailored toward a specific NEMOnode's characteristics and requirements, and can be designed to supporta variety of functionality ranging from traditional message queues tomore sophisticated distributed transaction coordinators. A relativelysimple WFC might provide an interface for storage and retrieval ofarbitrary service-related messages. By building on this, it is possibleto support a wide variety of functionality including (i) collection ofservice requests for more effective processing; (ii) simple aggregationof service responses into a composite response; (iii) manualorchestration of multiple service requests and service responses inorder to create a composite service; and (iv) automated orchestration ofmultiple service requests and service responses in order to create acomposite service.

A basic service interaction pattern begins with a service requestarriving at some NEMO node via the node's Service Adaptation Layer. Themessage is handed off to the WSDL Message Pump that initially will driveand in turn be driven by the WFC to fulfill the request and return aresponse. In even more complex scenarios, the fulfillment of a servicerequest might require multiple messages and responses and theparticipation of multiple nodes in a coordinated fashion. The rules forprocessing requests may be expressed in the system's service descriptionlanguage or using other service orchestration description standards suchas BPEL.

When a message is given to the WFC, the WFC determines the correct rulesfor processing this request. Depending upon the implementation of theWFC, the service description logic may be represented in the form of afixed state machine for a set of services that the node exposes or itmay be represented in ways that support the processing of a more freeform expression of the service processing logic.

In a preferred embodiment the WFC architecture is modular andextensible, supporting plug-ins. In addition to interpreting servicecomposition and processing rules, the WFC may need to determine whetherto use NEMO messages in the context of initiating a service fulfillmentprocessing lifecycle, or as input in the chain of an ongoingtransaction. In one embodiment, NEMO messages include IDs and metadatathat are used to make these types of determinations. NEMO messages alsocan be extended to include additional information that may be servicetransaction specific, facilitating the processing of messages.

As discussed in greater detail below, notification services are directlysupported by various embodiments of the NEMO system. A notificationrepresents a message targeted at interested NEMO-enabled nodes receivedon a designated service interface for processing. Notifications maycarry a diverse set of payload types for conveying information and thecriteria used to determine if a node is interested in a notification isextensible, including identity-based as well as event-based criteria.

In one embodiment, illustrated in FIG. 9 a, a service-providing NEMOnode 910 provides a service that requires an orchestration process byits Workflow Collator 914 (e.g., the collection and processing ofresults from two other service providers) to fulfill a request for thatservice from client node 940.

When NEMO-enabled application 942 on client node 940 initiates a requestto invoke the service provided by service provider 910, WorkflowCollator 914 in turn generates messages to initiate its own requests (onbehalf of application 942), respectively, to Service Provider “Y” 922 onnode 920 and Service Provider “Z” 932 on node 930. Workflow Collator 914then collates and processes the results from these two otherservice-providing nodes in order to fulfill the original request fromclient node 940.

Alternatively, a requested service might not require the services ofmultiple service-providing nodes; but might instead require multiplerounds or phases of communication between the service-providing node andthe requesting client node. As illustrated in FIG. 9 b, whenNEMO-enabled application 942 on client node 940 initiates a request toinvoke the service provided by service provider 910, Workflow Collator914 in turn engages in multiple phases of communication 950 with clientnode 940 in order to fulfill the original request. For example, WorkflowCollator 914 may generate and send messages to client node 940 (viaAccess Point 944), receive and process the responses, and then generateadditional messages (and receive additional responses) during subsequentphases of communication, ultimately fulfilling the original request fromclient node 940.

In this scenario, Workflow Collator 914 is used by service provider 910to keep track (perhaps based on a service-specific session ID ortransaction ID as part of the service request) of which phase of theoperation it is in with the client for correct processing. As notedabove, a state machine or similar mechanism or technique could beemployed to process these multiple phases of communication 950.

FIG. 9 c illustrates one embodiment of a relatively basic interaction,within service-providing node 960, between Workflow Collator 914 andMessage Pump 965 (within the node's Service Adaptation Layer, notshown). As noted above, Workflow Collator 914 processes one or moreservice requests 962 and generates responses 964, employing a storageand retrieval mechanism 966 to maintain the state of this orchestrationprocess. In this simple example, Workflow Collator 914 is able toprocess multiple service requests and responses, which could beimplemented with a fairly simple state machine.

For more complex processing, however, FIG. 9 d illustrates a nodearchitecture that can both drive or be driven in performing serviceorchestration. Such functionality includes the collection of multipleservice requests, aggregation of responses into a composite response,and either manual or automated orchestration of multiple servicerequests and responses in order to create a composite service.

A variety of scenarios can be supported by the architecture surroundingWorkflow Collator 914 in FIG. 9 d. For example, by having a NEMO nodecombine its functionality with that of an external coordinator 970 thatunderstands the semantics of process orchestration (such as a BusinessProcess Language engine driven by a high level description of thebusiness processes associated with services) or resource usage semantics(such as a Resource Description Framework engine which can be driven bythe semantic meaning of resources in relationship to each other), it ispossible to create more powerful services on top of simpler ones. CustomExternal BPL 972 and/or RDF 973 processors may leverage external messagepump 975 to execute process descriptions via a manual orchestrationprocess 966, i.e., one involving human intervention.

In addition to relying on a manually driven process that relies on anexternal coordinator working in conjunction with a NEMO node's messagepump, it is also possible to create an architecture where modules may beintegrated directly with Workflow Collator 914 to support an automatedform of service coordination and orchestration 968. For example, forregular types of service orchestration patterns, such as thoserepresented in BPEL and EBXML and communicated in the web servicebindings associated with a service interface, Workflow Collator 914 canbe driven directly by a description and collection of request andresponse messages 967 that arrive over time. In this scenario, acomposite response message is pushed to Message Pump 965 only when thestate machine associated with the given orchestration processor plug-in(e.g., BPEL 982 or EBXML 983) has determined that it is appropriate.

Following is an embodiment of a relatively high-level API descriptionexported by an embodiment of a NEMO Workflow Collator:

WorkflowCollator:Create(Environment[ ])→WorkflowCollator—this is asingleton interface that returns an initialized instance of a WFC. TheWFC can be initialized based on an optional set of environmentalparameters.WorkflowCollator:Store(Key[ ], XML Message)→Boolean—this API allows thecaller to store a service message within the WFC via a set of specifiedkeys.WorkflowCollator:RetrieveByKey(Key[ ], XML Message)→XML Message[ ]—thisAPI allows the caller to retrieve a set of messages via a set ofspecified keys. The returned messages are no longer contained within theWFC.WorkflowCollatoc:PeekByKey(Key[ ], XML Message)→XML Message[ ]—this APIallows the caller to retrieve a set of messages via a set of specifiedkeys. The returned messages are still contained within the WFC.WorkflowCollator::Clear( )→Boolean—this API allows the caller to clearany messages stored within the WFC.

As an alternative to the relatively rigid BPEL orchestration standard,another embodiment could permit a more ad hoc XML-based orchestrationdescription e.g., for a more dynamic application, such as a distributedsearch. Consider the following description that could be interpreted bya NEMO Workflow Collator (and could possibly even replace an entireservice given a sufficiently rich language):

<WSDL> <NEMO Orchestration Descriptor> <Control Flow> e.g., EXECUTEService A; If result = Yes then Service B; Else Service C <SharedState/Context> e.g., Device State <Transactions> e.g., State, Rollback,etc <Trust/Authorization> Note that Trust not necessarily transitive

3.6. Exemplary DRM Engine Architecture

In the context of the various embodiments of the NEMO node architecturedescribed above, FIG. 10 illustrates the integration of a modularembodiment of a DRM Engine 1000 into a NEMO content consumption device,thereby facilitating its integration into many different devices andsoftware environments.

Host application 1002 typically receives a request to access aparticular piece of content through its user interface 1004. Hostapplication 1002 then sends the request, along with relevant DRM engineobjects (preferably opaque to the host application), to DRM engine 1000.DRM engine 1000 may make requests for additional information andcryptographic services to host services module 1008 through well-definedinterfaces. For example, DRM engine 1000 may ask host services 1008whether a particular link is trusted, or may ask that certain objects bedecrypted. Some of the requisite information may be remote, in whichcase host services 1008 can request the information from networkedservices through a service access point 1014.

Once DRM engine 1000 has determined that a particular operation ispermitted, it indicates this and returns any required cryptographic keysto host services 1008 which, under the direction of host application1002, relies on content services 1016 to obtain the desired content andmanage its use. Host services 1008 might then initiate the process ofmedia rendering 1010 (e.g., playing the content through speakers,displaying the content on a screen, etc.), coordinated with cryptographyservices 1012 as needed.

The system architecture illustrated in FIG. 10 is a relatively simpleexample of how the DRM engine can be used in applications, but it isonly one of many possibilities. For example, in other embodiments, theDRM engine can be integrated into packaging applications under thegovernance of relatively sophisticated policy management systems. Bothclient (content consumption) and server (content packaging) applicationsof the DRM engine, including descriptions of the different types ofDRM-related objects relied upon by such applications, will be discussedbelow, following a description of one embodiment of the internalarchitecture of the DRM engine itself.

DRM Engine 1100, illustrated in FIG. 11, relies on a virtual machine,control VM 1110, for internal DRM processing (e.g., executing controlprograms that govern access to content) within a broad range of hostplatforms, utilizing host environment 1120 (described above, and ingreater detail below) to interact with the node's host application 1130and, ultimately, other nodes within, e.g., the NEMO or other system.

In one embodiment, control VM 1110 is a virtual machine used by anembodiment of DRM Engine 1100 to execute control programs that governaccess to content. Following is a description of the integration ofcontrol VM 1110 into the architecture of DRM engine 1100, as well assome of the basic elements of the control VM, including details aboutits instruction set, memory model, code modules, and interaction withhost environment 1120 via system calls 1106.

In one embodiment, control VM 1110 is a relatively small-footprintvirtual machine that is designed to be easy to implement using variousprogramming languages. It is based on a stack-oriented instruction setthat is designed to be minimalist in nature, without much concern forexecution speed or code density. However, it will be appreciated that,if execution speed and/or code density were issues in a givenapplication, conventional techniques (e.g., data compression) could beused to improve performance.

Control VM 1100 is suitable as a target for low or high levelprogramming languages, and supports languages such as assembler, C, andFORTH. Compilers for other languages, such as Java or custom languages,could also be implemented with relative ease.

Control VM 1110 is designed to be hosted within DRM Engine 1100,including host environment 1120, as opposed to being run directly on aprocessor or in silicon. Control VM 1110 runs programs by executinginstructions stored in Code Modules 1102. Some of these instructions canmake calls to functions implemented outside of the program itself bymaking one or more System Calls 1106, which are either implemented byControl VM 1110 itself, or delegated to Host Environment 1120.

Execution Model

Control VM 1110 executes instructions stored in code modules 1102 as astream of byte code loaded in memory 1104. Control VM 1110 maintains avirtual register called the program counter (PC) that is incremented asinstructions are executed. The VM executes each instruction, insequence, until the OP_STOP instruction is encountered, an OP_RETinstruction is encountered with an empty call stack, or an exceptionoccurs. Jumps are specified either as a relative jump (specified as abyte offset from the current value of PC), or as an absolute address.

Memory Model

In one embodiment, control VM 1110 has a relatively simple memory model.VM memory 1104 is separated into a data segment (DS) and a code segment(CS). The data segment is a single, flat, contiguous memory space,starting at address 0. The data segment is typically an array of bytesallocated within the heap memory of host application 1130 or hostenvironment 1120. For a given VM implementation, the size of the memoryspace is preferably fixed to a maximum; and attempts to access memoryoutside of that space will cause faults and terminate program execution.The data segment is potentially shared between several code modules 1102concurrently loaded by the VM. The memory in the data segment can beaccessed by memory-access instructions, which can be either 32-bit or8-bit accesses. 32-bit memory accesses are accomplished using thebig-endian byte order. No assumptions are made with regard to alignmentbetween the VM-visible memory and the host-managed memory (host CPUvirtual or physical memory).

In one embodiment, the code segment is a flat, contiguous memory space,starting at address 0. The code segment is typically an array of bytesallocated within the heap memory of host application 1130 or hostenvironment 1120.

Control VM 1110 may load several code modules, and all of the codemodules may share the same data segment (each module's data ispreferably loaded at a different address), but each has its own codesegment (e.g., it is preferably not possible for a jump instruction fromone code module 1102 to cause a jump directly to code in another codemodule 1102).

Data Stack

In a preferred embodiment, the VM has a notion of a data stack, whichrepresents 32-bit data cells stored in the data segment. The VMmaintains a virtual register called the stack pointer (SP). After reset,SP points to the end of the data segment, and the stack grows downward(when data is pushed onto the data stack, the SP registers aredecremented). The 32-bit values on the stack are interpreted either as32-bit addressed, or 32-bit signed, integers, depending on theinstruction referencing the stack data.

Call Stack

In one embodiment, control VM 1110 manages a call stack for makingnested subroutine calls. The values pushed onto this stack cannot beread or written directly by the memory-access instructions, but are usedindirectly by the VM when executing OP_JSR and OP_RET instructions. Fora given VM profile, the size of this return address stack is preferablyfixed to a maximum, which will allow a certain number of nested callsthat cannot be exceeded.

Instruction Set

In one embodiment, control VM 1110 uses a relatively simple instructionset. Even with a limited number of instructions; however, it is stillpossible to express simple programs. The instruction set is stack-based:except for the OP_PUSH instruction, none of the instructions have directoperands. Operands are read from the data stack, and results are pushedonto the data stack. The VM is a 32-bit VM: all the instructions in thisillustrative embodiment operate on 32-bit stack operands, representingeither memory addresses or signed integers. Signed integers arerepresented using a 2s complement binary encoding.

An illustrative instruction set used in one embodiment is shown below:

OP CODE Name Operands Description OP_PUSH Push N (direct) Push aconstant on the stack Constant OP_DROP Drop Remove top of stack OP_DUPDuplicate Duplicate top of stack OP_SWAP Swap Swap top two stackelements OP_ADD Add A, B Push the sum of A and B (A + B) OP_MUL MultiplyA, B Push the product of A and B (A * B) OP_SUB Subtract A, B Push thedifference between A and B (A − B) OP_DIV Divide A, B Push the divisionof A by B (A/B) OP_MOD Modulo A, B Push A modulo B (A % B) OP_NEG NegateA Push the 2s complement negation of A (−A) OP_CMP Compare A Push −1 ifA negative, 0 if A is 0, and 1 is a positive OP_AND And A, B Pushbit-wise AND of A and B (A & B) OP_OR Or A, B Push the bit-wise OR of Aand B (A| B) OP_XOR Exclusive Or A, B Push the bit-wise eXclusive OR ofA and B (A {circumflex over ( )} B) OP_NOT Logical A Push the logicalnegation of A (1 if Negate A is 0, and 0 if A is not 0) OP_SHL ShiftLeft A, B Push A logically shifted left by B bits (A << B) OP_SHR ShiftRight A, B Push A logically shifted right by B bits (A >> B) OP_JSR Jumpto A Jump to subroutine at absolute Subroutine address A OP_JSRR Jump toA Jump to subroutine at PC + A Subroutine (Relative) OP_RET Return fromReturn from subroutine Subroutine OP_BRA Branch A Jump to PC + A AlwaysOP_BRP Branch if A, B Jump to PC + A if B > 0 Positive OP_BRN Branch ifA, B Jump to PC + A if B > 0 Negative OP_BRZ Branch if A, B Jump to PC +A if B is 0 Zero OP_JMP Jump A Jump to A OP_PEEK Peek A Push the 32-bitvalue at address A OP_POKE Poke A, B Store the 32-bit value B at addressA OP_PEEKB Peek Byte A Push the 8-bit value at address A OP_POKEB PokeByte A, B Store the least significant bits of B at address A OP_PUSHSPPush Stack Push the value of SP Pointer OP_POPSP Pop Stack A Set thevalue of SP to A Pointer OP_CALL System Call A Perform System Call withindex A OP_STOP Stop Terminate Execution

Module Format

In one embodiment, code modules 1102 are stored in an atom-based formatthat is essentially equivalent to the atom structure used in the MPEG-4file format. An atom consists of 32 bits, stored as 4-octets inbig-endian byte order, followed by a 4-octet type (usually octets thatcorrespond to ASCII values of letters of the alphabet), followed by thepayload of the atom (size-8 octets).

3.7. DRM Client-Server Architecture: Content Consumption and Packaging

As noted above, DRM client-side consuming applications (e.g., mediaplayers) consume DRM content (e.g., play a song, display a movie, etc.).DRM service-side packaging applications (typically residing on a server)package content (e.g., associate with the content relevant usage anddistribution rights, cryptographic keys, etc.) targeted to DRM clients.

FIG. 12 a illustrates one embodiment of the main architectural elementsof a DRM client. Host application 1200 interfaces with a device user(e.g., the owner of a music player) through user interface 1210. Theuser might, for example, request access to protected content and receivemetadata along with the content (e.g., text displaying the name of theartist and song title, along with the audio for the song itself).

Host application 1200, in addition to interacting with user interface1210, also performs various functions necessary to implement the user'srequest, which may include managing interaction with the other DRMclient modules to which it delegates certain functionality. For example,host application 1200 may manage interaction with the file system toextract the requested content. Host application also preferablyrecognizes the protected content object format and issues a request tothe DRM engine 1220 to evaluate the DRM objects that make up the license(e.g., by running the relevant control program) to determine whetherpermission to access the protected content should be granted.

If permission is granted, Host Application 1200 might also need toverify required signatures and delegate to crypto services 1230 anyother general purpose cryptographic functions required by DRM engine1220. DRM Engine 1220 is responsible for evaluating the DRM objects,confirming or denying permission, and providing the keys to hostapplication 1200 to decrypt the content.

Host services 1240 provides DRM Engine 1220 with access to data managedby (as well as certain library functions implemented by) hostapplication 1200. Host application 1200 interacts with content services1250 to access the protected content, passing to DRM engine 1220 onlythat portion of the content requiring processing. Content services 1250acquires the content from external media servers and stores and managesthe content, relying on the client's persistent storage mechanisms.

Once the content is cleared for access, host application 1200 interactswith media rendering engine 1260 (e.g., by delivering keys) to decryptand render the content via the client's AV output facilities. Some ofthe information needed by DRM Engine 1220 may be available in-band withthe content, and can be acquired and managed via content services 1250,while other information may need to be obtained through external NEMODRM services or some other source.

In a preferred embodiment, all of the cryptographic operations(encryption, signature verification, etc.) are handled by cryptoservices 1230, which interacts indirectly with DRM engine 1220 via hostservices 1240, which forwards requests. Crypto services 1230 can also beused by media rendering engine 1260 to perform content decryption.

Turning to the service side, FIG. 12 b illustrates an embodiment of themain architectural elements of an exemplary DRM service-side packagingnode. Host application 1200 interfaces with a content packager (e.g., anowner or distributor of music content) through user interface 1210. Thepackager might, for example, provide content and licensing informationto host application 1200 so that the content can be protected (e.g.,encrypted and associated with limited access rights) and distributed tovarious end user and intermediate content providing nodes.

Host application 1200, in addition to interacting with user interface1210, can also perform various functions necessary to implement thepackager's request, including, for example, managing interaction withthe other DRM packaging modules to which it delegates certainfunctionality. For example, it may manage interaction with generalcrypto services 1235 to encrypt the content. It may also create acontent object that contains or references the content and contains orreferences a license (e.g., after DRM packaging engine 1225 creates theDRM objects that make up the license). Metadata can be associated withthe license that explains what the license is about in a human-readableway (e.g., for potential client users to view).

As noted above, host application 1200 interacts with the user via userinterface 1210. It is responsible for getting information such as acontent reference and the action(s) the packager wants to perform (e.g.,who to bind the content to). It can also display information about thepackaging process such as the text of the license issued and, if afailure occurs, the reason for this failure. Some information needed byhost application 1200 may require the use of NEMO Services 1270 (e.g.,to leverage services such as authentication or authorization as well asmembership).

In one embodiment, host application 1200 delegates to media formatservices 1255 responsibility for managing all media format operations,such as transcoding and packaging. General crypto services 1235 isresponsible for issuing and verifying signatures, as well as encryptingand decrypting certain data. The request for such operations could beissued externally or from DRM packaging engine 1225 via host services1240.

In one embodiment, content crypto services 1237 is logically separatedfrom general crypto services 1235 because it is unaware of hostapplication 1200. It is driven by media format services 1255 at contentpackaging time with a set of keys previously issued by DRM packagingengine 1225 (all of which is coordinated by host application 1200).

3.8. DRM Content Protection and Governance Objects

In an illustrative scenario, a content provider uses a host applicationthat relies on a DRM packager engine to create a set of objects thatprotect the content and govern its use, including conveying theinformation necessary for obtaining the content encryption keys. Theterm, license, is used to encompass this set of objects.

In a preferred embodiment, the content and its license are logicallyseparate, but are bound together by internal references using objectIDs. The content and license are usually stored together, but could bestored separately if necessary or desirable. A license can apply to morethan one item of content, and more than one license can apply to anysingle item of content.

FIG. 13 illustrates an embodiment of such a license, including therelationships among the set of objects discussed below. Note thatcontrol object 1320 and controller object 1330 are both signed objectsin this embodiment, so that the DRM client engine can verify that thecontrol information comes from a trusted source prior to providing thehost application with permission to access the protected content. Inthis embodiment, all of these objects, with the exception of contentobject 1300, are created by the DRM client engine.

Content object—Content object 1300 represents the encrypted content1304, using a unique ID 1302 to facilitate the binding between thecontent and its associated key. Content object 1300 is an “external”object. The format and storage of encrypted content 1304 (e.g., MP4movie file, MP3 music track, etc.) is determined by the host application(or delegated to a service), based in part upon the type of content. Theformat of the content also provides support for associating ID 1302 withencrypted content 1304. The packager's host application encrypts thecontent in a format-dependent manner, and manages content object 1300,using any available cryptosystem (e.g., using a symmetric cipher, suchas AES).

ContentKey object—ContentKey object 1310 represents the encrypted keydata 1314 (including a unique encryption key(s), optionally storedinternally within the object), and also has a corresponding unique ID1312. Preferably, this key data, if contained within ContentKey object1310, is itself encrypted so that it can only be identified by thoseauthorized to decrypt the content. ContentKey object 1310 also specifieswhich cryptosystem was used to encrypt this key data. This cryptosystem,an embodiment of which is discussed in greater detail below, is referredto as the “key distribution system.”

Control object—Control object 1320 includes and protects the controlprogram (e.g., control byte code 1324) that represents the rules thatgovern the use of the keys used to encrypt and decrypt the content. Italso includes ID 1322 so that it can be bound to the correspondingContentKey object. As noted above, control object 1320 is signed so thatthe DRM client engine can verify the validity of the binding between theContentKey 1310 and control 1320, as well as the binding between theContentKey ID 1312 and the encrypted key data 1314. The validity ofcontrol byte code 1324 can optionally be derived by verifying a securehash (e.g., control hash 1338, if available) contained in controllerobject 1330.

Controller object—Controller object 1330 represents the binding betweenthe keys and the rules governing their control, using IDs 1312 and 1322,respectively, to bind the ContentKey 1310 and control 1320 objects.Controller object 1330 governs the use of protected content bycontrolling application of the rules to that content—i.e., bydetermining which control governs the use of which ContentKey object1310. Controller object 1330 also contains a hash 1336 value for each ofthe ContentKey objects 1310 that it references, in order to preventtampering with the binding between each ContentKey object 1310 and itscorresponding encrypted key data 1314. As noted above, controllerobjects 1330 are preferably signed (e.g., by a packager application thathas a certificate allowing it to sign controller objects, using publickey or symmetric key signatures, as discussed below) to enableverification of the validity of the binding between the ContentKey 1310and control 1320 objects, as well as the binding between the ContentKeyID 1312 and the encrypted key data 1314. As also noted above, controllerobject 1330 also optionally contains control hash 1338, which allows thevalidity of control object 1320 to be derived without having toseparately verify its signature.

Symmetric Key Signature—In a preferred embodiment, a symmetric keysignature is the most common type of signature for controller objects1330. In one embodiment, this type of signature is implemented bycomputing a MAC (Message Authentication Code) of the controller object1330, keyed with the same key as the key represented by the ContentKeyobject 1310.

Public Key Signature—In a preferred embodiment, this type of signatureis used when the identity of the signer of the controller object 1330needs to be asserted uniquely. This type of signature is implementedwith a public key signature algorithm, signing with the private key ofthe principal who is asserting the validity of this object. When usingthis type of signature, the ContentKey binding information carried inthe controller object 1330 preferably contains a hash 1336 of the keycontained in the ContentKey object 1310, concatenated with a fingerprintof the signing private key (typically a hash of the private key). Thisbinding ensures that the signer of the object has knowledge of the keyused to protect the content.

Protector object—Protector object 1340 provides protected access tocontent by controlling the use of keys used to encrypt and decrypt thatcontent. Protector object 1340 binds content object 1300 to ContentKeyobject 1310 in order to associate protected content with itscorresponding key(s). To accomplish this binding, it includes references1342 and 1344, respectively, to the IDs 1302 and 1312 of content 1300and ContentKey 1310. In one embodiment, protector object 1340 containsinformation not only as to which key was used to encrypt one or morecontent items, but also as to which encryption algorithm was employed.In one embodiment, if content reference 1342 references more than onecontent object 1300, ContentKey reference 1344 may still reference onlyone ContentKey object 1310, indicating that all of those content itemswere encrypted using the same encryption algorithm and the same key.

3.9. DRM Node and Link Objects

While FIG. 13 illustrates the content protection and governance objectscreated by DRM engines to control access to protected content, FIG. 14illustrates the DRM objects that represent entities in the system (e.g.,users, devices or groups), as well as the relationships among thoseentities.

While FIG. 4, discussed above, illustrates a conceptual embodiment of anode or authorization graph depicting these entities and theirrelationships, FIG. 14 illustrates two types of objects that implementan embodiment of this conceptual graph: vertex (or “node”) objects (1400a and 1400 b), which represent entities and their attributes, and linkobjects (1420), which represent the relationships among node objects. Inone embodiment, the DRM engine, by executing control programs,instigates one or more usage patterns involving these objects—e.g.,encrypting a song and associating it with a license that restricts itsdistribution to particular individuals. Yet, the DRM engine in thisembodiment does not specify, implicitly or explicitly, the semanticsattached to these objects (e.g., to which individuals the song may bedistributed).

In one embodiment this semantic context, referred to as a DRM profile,is defined within the attributes of the node objects themselves. A DRMprofile may include descriptions of these entities and the various rolesand identities they represent, typically expressed using node attributes(1401 a and 1401 b). As discussed above, a link 1420 between two nodes1400 a and 1400 b could represent various types of semanticrelationships. For example, if one node was a “user” and the other was a“device,” then link 1420 might represent “ownership.” If the other nodewas a “user group” instead of a “device,” then link 1420 might represent“membership.” Link 1420 might be unidirectional in one scenario andbidirectional in another (e.g., representing two links between the sametwo nodes).

Node objects 1400 a and 1400 b also typically have objectconfidentiality protection asymmetric key pairs (e.g., private key 1405a and public key 1406 a of node 1400 a, and private key 1405 b andpublic key 1406 b of node 1400 b) to limit confidential information toauthorized portions of the node. Confidential information targeted at anode will be encrypted with that node's confidentiality protectionpublic key. Optionally, a content protection asymmetric key pair (e.g.,private key 1403 a and public key 1403 b of node 1400 a, and private key1403 b and public key 1403 b of node 1400 b) can be used in conjunctionwith link objects when the system uses a ContentKey derivation systemfor ContentKey distribution, as discussed in greater detail below.Content items themselves may be protected with content protectionsymmetric keys, such as symmetric key 1402 a of node 1400 a and key 1402b of node 1400 b.

As noted above, in one embodiment link objects (e.g., link 1420)represent relationships between nodes. The semantics of theserelationships can be stored in node attributes (e.g., 1401 a of node1400 a and 1401 b of node 1400 b), referenced from within the linkobjects (e.g., node reference 1422 to node 1400 a and node reference1424 to node 1400 b). Link objects can also optionally containcryptographic data (e.g., key derivation info 1426) that enables thelink object to be used for ContentKey derivations, as discussed below.

In one embodiment the link object itself is a signed object, representedby a directed edge in a graph, such as in FIG. 4 above. When thereexists such a directed edge from one node (e.g., node X) to another(e.g., node Y), this “path” from node X to node Y indicates that node Yis “reachable” from node X. The existence of a path can be used by otherDRM objects, e.g., as a condition of performing a particular function. Acontrol object might check to determine whether a target node isreachable before it allows a certain action to be performed on itsassociated content object.

For example, if node D represents a device that wants to perform the“play” action on a content object, a control that governs this contentobject might test whether a certain node U representing a certain useris reachable from node D (e.g., whether that user is the “owner” of thatdevice), and only allow the “play” action to be performed if thatcondition is satisfied. To determine if node U is reachable, the DRMengine can run a control program to determine whether there exists a setof link objects that can establish a path (e.g., a direct or indirectrelationship) between node D and node U. As noted above, in oneembodiment the DRM engine is unaware of the semantics of therelationship; it simply determines the existence of a path, enabling thehost application, for example, to interpret this path as a conditionalauthorization, permitting access to protected content.

In one embodiment the DRM engine verifies link objects before allowingthem to be used to determine the existence of paths in the system nodegraph. The validity of a link object at any given time may depend uponthe particular features of the certificate system (discussed below) usedto sign link objects. For example, they may have limited “lifetimes” orbe revoked or revalidated from time to time based on various conditions.

Also, in one embodiment the policies that govern which entities can signlink objects, which link objects can be created, and the lifetime oflink objects are not directly handled by the DRM engine. Instead, theymay leverage the node attributes information. To facilitate the task ofenforcing certain policies, the system may provide a way to extendstandard certificate formats with additional constraint checking. Theseextensions make it possible to express validity constraints oncertificates for keys that sign links, such that constraints (e.g., thetype of nodes connected by the link, as well as other attributes), canbe checked before a link is considered valid.

Finally, in one embodiment the link object may contain cryptographicdata that provides the user with the nodes' content protection keys forkey distribution. That cryptographic data may, for example, contain, inaddition to metadata, the private and/or symmetric content protectionkeys of the “from” node, encrypted with the content protection publickey and/or the content protection symmetric key of the “to” node. Forexample, an entity that has been granted the ability to create linkobjects that link device nodes and user nodes under a certain policy maycheck to ensure that it only creates links between node objects thathave attributes indicating they are indeed representing a device, andnodes that have attributes indicating that they represent a user.

3.10. DRM Cryptographic Keys

An example embodiment of a DRM key distribution system is illustrated inFIG. 15. The basic principle behind the key distribution system shown inFIG. 15 is to use link objects to distribute keys in addition to theirprimary purpose of establishing relationships between node objects.

As noted above, a control object may contain a control program thatdetermines whether a requested operation should be permitted. Thatcontrol program may check to determine whether a specific node isreachable via a collection of link objects. The key distribution systemshown in FIG. 15 leverages that search through a collection of linkobjects to facilitate the distribution of a key such that it isavailable to the DRM engine that is executing the control program.

In one embodiment, each node object that uses the key distributionsystem has one or more keys. These keys are used to encrypt content keysand other nodes' key distribution keys. Link objects created for use inthe same deployment contain some cryptographic data payload that allowskey information do be derived when chains of links are processed by theDRM engine.

With nodes and links carrying keys this way, given a collection of links(e.g., from a node A to a node B . . . to a node Z), any entity that hasaccess to the private keys of node A also has access to the private keysof node Z. Having access to node Z's private keys gives the entityaccess to any content key encrypted with those keys.

Node objects that participate in a key distribution system contain keysas part of their data. As illustrated in FIG. 15, in one embodiment eachnode (1500 a, 1500 b, and 1500 c) has three keys:

Public Key Kpub[N]—This is the public part of a pair of public/privatekeys for the public key cipher. In one embodiment this key (1505 a, 1505b and 1505 c, respectively, in nodes 1500 a, 1500 b and 1500 c) comeswith a certificate (discussed below) so that its credentials can beverified by entities that want to bind confidential information to itcryptographically.Private Key Kpriv[N]—This is the private part of the public/private keypair. The entity that manages the node is responsible for ensuring thatthis private key (keys 1515 a, 1515 b and 1515 c, respectively, in nodes1500 a, 1500 b and 1500 c) is kept secret. For that reason, in oneembodiment this private key is stored and transported separately fromthe rest of the node information.Symmetric Key Ks[N]—This key is used with a symmetric cipher (discussedbelow). Because this private key (keys 1525 a, 1525 b and 1525 c,respectively, in nodes 1500 a, 1500 b and 1500 c) is confidential, theentity that manages the node is responsible for keeping it secret.

The key distribution system illustrated in FIG. 15 can be implementedusing different cryptographic algorithms, though the participatingentities will generally need to agree on a set of supported algorithms.In one embodiment, at least one public key cipher (such as RSA) and onesymmetric key cipher (such as AES) are supported.

The following notation refers to cryptographic functions:

Ep(kpub[N], M) means “the message M encrypted with the public key Kpubof node N, using a public key cipher”Dp(Kpriv[N], M) means “the message M decrypted with the private keyKpriv of node N using a public key cipher”Es(Ks[N], M) means “the message M encrypted with the symmetric key Ks ofnode N using a symmetric key cipher”Ds(Ks[N], M) means “the message M decrypted with the symmetric key Ks ofnode N using a symmetric key cipher”

Targeting a “ContentKey” to a node means making that key available tothe entities that have access to the private keys of that node. In oneembodiment binding is done by encrypting the key using one or both ofthe following methods:

Public Binding Create a ContentKey object that contains Ep(Kpub[N], CK)Symmetric Binding Create a ContentKey object that contains Es(Ks[N], CK)

In this embodiment, symmetric binding is preferably used wheneverpossible, as it uses a less computationally intensive algorithm that isless onerous on the receiving entity. However, the entity (e.g., acontent packager) that creates the ContentKey object may not always haveaccess to Ks[N]. In that case, public binding can be used, as Kpub[N]should be available, as it is not confidential information. Kpub[N] willusually be made available to entities that need to target ContentKeys,accompanied by a certificate that can be inspected by the entity todecide whether Kpub[N] is indeed the key of a node that can be trustedto handle the ContentKey in accordance with some agreed-upon policy.

To allow entities to have access to the distribution keys of allreachable nodes, in one embodiment link objects contain a “payload.”That payload allows any entity that has access to the private keys ofthe link's “from node” to also have access to the private keys of thelink's “to node.” In this manner, an entity can decrypt any ContentKeytargeted to a node that is reachable from its node.

Thus, returning to FIG. 15, link 1530 a, which links node 1500 a to node1500 b, contains a payload that is created by encrypting the privatekeys 1515 b and 1525 b of node 1500 b with either the symmetric key 1515a of node 1500 a or, if unavailable (e.g., due to its confidentiality),with the public key 1525 a of node 1500 a. Similarly, link 1530 b, whichlinks node 1500 b to node 1500 c, contains a payload that is created byencrypting the private keys 1515 c and 1525 c of node 1500 c with eitherthe symmetric key 1515 b of node 1500 b or, if unavailable, with thepublic key 1525 b of node 1500 b.

When a DRM engine processes link objects, it processes the payload ofeach link to update an internal chain 1550 of keys to which it hasaccess. In one embodiment the payload of a link from node A to node Bconsists of either:

Public Derivation Information Ep(Kpub[A], {Ks[B],Kpriv[B]})

or

Symmetric Derivation Information Es(Ks[A], {Ks[B], Kpriv[B]})

Where {Ks[B], Kpriv[B} is a data structure containing Ks[B] andKpriv[B].

The public derivation information is used to convey the private keys ofnode B, Ks[B] and Kpriv[B], to any entity that has access to the privatekey of node A, Kpriv[A]. The symmetric derivation information is used toconvey the private keys of node B, Ks[B] and Kpriv[B], to any entitythat has access to the symmetric key of node A, Kpriv[A].

Thus, with reference to key chain 1550, an entity that has access to theprivate keys of node 1500 a (private key 1515 a and symmetric key 1525a) enables the DRM engine to utilize these private keys 1560 as a “firstlink” in (and starting point in generating the rest of) key chain 1550.Scuba keys 1560 are used to decrypt 1555 a the ContentKey object withinlink 1530 a (using private key 1515 a for public derivation if publicbinding via public key 1505 a was used, or symmetric key 1525 a forsymmetric derivation if symmetric binding via symmetric key 1525 a wasused), resulting in the next link 1570 in key chain 1550 i.e., theconfidential keys of node 1500 b (private key 1515 b and symmetric key1525 b). The DRM engine uses these keys 1570 in turn to decrypt 1555 bthe ContentKey object within link 1530 b (using private key 1515 b forpublic derivation if public binding via public key 1505 b was used, orsymmetric key 1525 b for symmetric derivation if symmetric binding viasymmetric key 1525 b was used), resulting in the final link 1580 in keychain 1550 i.e., the confidential keys of node 1500 c (private key 1515c and symmetric key 1525 c).

Since, in one embodiment, the DRM engine can process links in any order,it may not be able to perform a key derivation at the time a link isprocessed (e.g., because the keys of the “from” node of that link havenot yet been derived). In that case, the link is remembered, andprocessed again when such information becomes available (e.g., when alink is processed in which that node is the “to” node).

3.11. DRM Certificates

As noted above, in one embodiment certificates are used to check thecredentials associated with cryptographic keys before making decisionsbased on the digital signature created with those keys. In oneembodiment, multiple certificate technologies can be supported,leveraging existing information typically available as standard elementsof certificates, such as validity periods, names, etc. In addition tothese standard elements, additional constraints can be encoded to limitpotential usage of a certified key.

In one embodiment this is accomplished by using key-usage extensions aspart of the certificate-encoding process. The information encoded insuch extensions can be used to enable the DRM engine to determinewhether the key that has signed a specific object was authorized to beused for that purpose. For example, a certain key may have a certificatethat allows it to sign only those link objects in which the link is froma node with a specific attribute, and/or to a node with another specificattribute.

The base technology used to express the certificate typically is notcapable of expressing such a constraint, as its semantics may be unawareof elements such as links and nodes. In one embodiment such specificconstraints are therefore conveyed as key usage extensions of the basiccertificate, including a “usage category” and a corresponding“constraint program.”

The usage category specifies which type of objects a key is authorizedto sign. The constraint program can express dynamic conditions based oncontext. In one embodiment a verifier that is being asked to verify thevalidity of such a certificate is required to understand the relevantsemantics, though the evaluation of the key usage extension expressionis delegated to the DRM engine. The certificate is considered valid onlyif the execution of that program generates a successful result.

In one embodiment, the role of a constraint program is to return aboolean value—e.g., “true” indicating that the constraint conditions aremet, and “false” indicating that they are not met. The control programmay also have access to some context information that can be used toreach a decision. The available context information may depend upon thetype of decision being made by the DRM engine when it requests theverification of the certificate. For example, before using theinformation in a link object, a DRM engine may verify that thecertificate of the key that signed the object allows that key to be usedfor that purpose. When executing the constraint program, the environmentof the DRM engine is populated with information regarding the link'sattributes, as well as the attributes of the nodes referenced by thatlink.

The constraint program embedded in the key usage extension is encoded,in one embodiment, as a code module (described above). This code modulepreferably exports at least one entry point named, for example,

“EngineName.Certificate.<Category>.Check”, where Category is a nameindicating which category of certificates need to be checked. Parametersto the verification program will be pushed onto the stack before callingthe entry point. The number and types of parameters passed onto thestack depends on the category of certificate extension being evaluated.

4. System Operation

4.1. Basic Node Interaction

Having examined various embodiments of the principal architecturalelements of the NEMO system, including embodiments in the context of DRMapplications, we now turn to the NEMO system in operation—i.e., thesequence of events within and among NEMO nodes that establish thefoundation upon which application-specific functionality can be layered.

In one embodiment, before NEMO nodes invoke application-specificfunctionality, they go through a process of initialization andauthorization. Nodes initially seek to discover desired services (viarequests, registration, notification, etc.), and then obtainauthorization to use those services (e.g., by establishing that they aretrustworthy and that they satisfy any relevant service providerpolicies).

This process is illustrated in FIG. 16, which outlines a basicinteraction between a Service Provider 1600 (in this embodiment, withfunctionality shared between a Service Providing Node 1610 and anAuthorizing Node 1620) and a Service Requester 1630 (e.g., a clientconsumer of services). Note that this interaction need not be direct.Any number of Intermediary Nodes 1625 may lie in the path between theService Requester 1630 and the Service Provider 1600. The basic steps inthis process, which will be described in greater detail below, arediscussed from the perspectives of both the client Service Requester1630 and Service Provider 1600.

From the perspective of the Service Requester 1630, the logical flow ofevents shown in FIG. 16 is as follows:

Service Discovery—In one embodiment, Service Requester 1630 initiates aservice discovery request to locate any NEMO-enabled nodes that providethe desired service, and obtain information regarding which servicebindings are supported for accessing the relevant service interfaces.Service Requester 1630 may choose to cache information about discoveredservices. It should be noted that the interface/mechanism for ServiceDiscovery between NEMO Nodes is just another service a NEMO Node choosesto implement and expose. The Service Discovery process is described ingreater detail below, including other forms of communication, such asnotification by Service Providers to registered Service Requesters.Service Binding Selection—Once candidate service-providing Nodes arefound, the requesting Node can choose to target (dispatch a request to)one or more of the service-providing Nodes based on a specific servicebinding.Negotiation of Acceptable Trusted Relationship with Service Provider—Inone embodiment, before two Nodes can communicate in a secure fashion,they must be able to establish a trusted relationship for this purpose.This may include an exchange of compatible trust credentials (e.g. X.500certificates, tokens, etc.) in some integrity-protected envelope thatmay be used to determine identity; and/or it may include establishing asecure channel, such as an SSL channel, based on certificates bothparties trust. In some cases, the exchange and negotiation of thesecredentials may be an implicit property of the service interface binding(e.g. WS-Security if the WS-I XML Protocol is used when the interface isexposed as a web service, or an SSL request between two well-knownnodes). In other cases, the exchange and negotiation of trustcredentials may be an explicitly separate step. NEMO provides a standardand flexible framework allowing Nodes to establish trusted channels forcommunication. It is up to a given Node, based on the characteristics ofthe Node and on the characteristics of the service involved in theinteraction, to determine which credentials are sufficient forinteracting with another NEMO Node, and to make the decision whether ittrusts a given Node. In one embodiment the NEMO framework leveragesexisting and emerging standards, especially in the area ofsecurity-related data types and protocols. For example, in oneembodiment the framework will support using SAML to describe bothcredentials (evidence) given by service requestors to service providerswhen they want to invoke a service, as well as using SAML as a way ofexpressing authorization queries and authorization responses.Creation of Request Message—The next step is for Requesting Node 1630 tocreate the appropriate request message(s) corresponding to the desiredservice. This operation may be hidden by the Service Access Point. Asnoted above, the Service Access Point provides an abstraction andinterface for interacting with service providers in the NEMO framework,and may hide certain service invocation issues, such as nativeinterfaces to service message mappings, objectserialization/de-serialization, negotiation of compatible messageformats, transport mechanisms or message routing issues, etc.Dispatching of Request—Once the request message is created, it isdispatched to the targeted service-providing Node(s)—e.g., Node 1610.The communication style of the request can be synchronous/asynchronousRPC style or message-oriented, based on the service binding and/orpreferences of the requesting client. Interacting with a service can bedone directly by the transmission and processing of service messages ordone through more native interfaces through the NEMO Service AccessPoint.Receiving Response Message(s)—After dispatching the request, RequestingNode 1610 receives one or more responses in reply. Depending on thespecifics of the service interface binding and the preferences ofRequesting Node 1610, the reply(s) can be returned in various ways,including an RPC-style response or notification message. As noted above,requests and replies can be routed to their targeted Node via otherintermediary Node(s) 1625, which may themselves provide a number ofservices, including: routing, trust negotiation, collation andcorrelation functions, etc. All services in this embodiment are“standard” NEMO services described, discovered, authorized, bound to,and interacted with in the same consistent framework. The Service AccessPoint may hide message-level abstractions from the Node. For examplefrom the Node's perspective, invocation of a service may seem like astandard function invocation with a set of simple fixed parameters.Validation of Response re Negotiated Trust Semantics—In one embodiment,Requesting Node 1630 validates the response message to ensure that itadheres to the negotiated trust semantics between it and the ServiceProviding Node 1610. This logic typically is completely encapsulatedwithin the Service Access Point.Processing of Message Payload—Finally, any appropriate processing isthen applied based on the (application specific) message payload typeand contents.

Following are the (somewhat similar) logical flow of events from theperspective of the Service Provider 1600:

Service Support Determination—A determination is first made as towhether the requested service is supported. In one embodiment, the NEMOframework doesn't mandate the style or granularity of how a serviceinterface maps as an entry point to a service. In the simplest case, aservice interface maps unambiguously to a given service, and the act ofbinding to and invoking that interface constitutes support for theservice. However, it may be the case that a single service interfacehandles multiple types of requests, or that a given service typecontains additional attributes which need to be sampled before adetermination can be made as to whether the Node really supports thespecifically desired functionality.Negotiation of Acceptable Trusted Relationship with Service Requester—Insome cases, it may be necessary for Service Provider 1600 to determinewhether it trusts Requesting Node 1630, and establish a trustedcommunication channel. This process is explained in detail above.Dispatch Authorization Request to Nodes Authorizing Access to ServiceInterface—Service Providing Node 1610 then determines whether RequestingNode 1630 is authorized or entitled to have access to the service, and,if so, under what conditions. This may be a decision based on localinformation, or on a natively supported authorization decisionmechanism. If not supported locally, Service Providing Node 1610 maydispatch an authorization request(s) to a known NEMO authorizationservice provider (e.g., Authorizing Node 1620) that governs itsservices, in order to determine if the Requesting Node 1610 isauthorized to have access to the requested services. In many situations,Authorizing Node 1620 and Service Providing Node 1610 will be the sameentity, in which case the dispatching and processing of the authorizingrequest will be local operations invoked through a lightweight serviceinterface binding such as a C function entry point. Once again, however,since this mechanism is itself just a NEMO service, it is possible tohave a fully distributed implementation. Authorization requests canreference identification information and/or attributes associated withthe NEMO Node itself, or information associated with users and/ordevices associated with the Node.Message Processing Upon Receipt of Authorization Response—Upon receivingthe authorization response, if Requesting Node 1630 is authorized,Service Provider 1600 performs the necessary processing to fulfill therequest. Otherwide, if Requesting Node 1630 is not authorized, anappropriate “authorization denied” response message can be generated.Return Response Message—The response is then returned based on theservice interface binding and the preferences of Requesting Node 1630,using one of several communication methods, including an RPC-styleresponse or notification message. Once again, as noted above, requestsand replies can be routed to their targeted Node via other IntermediaryNode(s) 1625, which may themselves provide a number of services,including routing, trust negotiation, collation and correlationfunctions, etc. An example of a necessary service provided by anIntermediary Node 1625 might be delivery to a notification processingNode that can deliver the message in a manner known to Requesting Node1630. An example of a “value added” service might be, for example, acoupon service which associates coupons to the response if it knows ofthe interests of Requesting Node 1630.

4.2. Notification

As noted above, in addition to both asynchronous and synchronousRPC-like communication patterns, where the client specifically initiatesa request and then either waits for responses or periodically checks forresponses through redemption of a ticket, some NEMO embodiments alsosupport a pure messaging type of communication pattern based on thenotion of notification. The following elements constitute data andmessage types supporting this concept of notification in one embodiment:

Notification—a message containing a specified type of payload targetedat interested endpoint Nodes.Notification Interest—criteria used to determine whether a given Nodewill accept a given notification. Notification interests may includeinterests based on specific types of identity (e.g., Node ID, user ID,etc.), events (e.g., Node discovery, service discovery, etc.), affinitygroups (e.g., new jazz club content), or general categories (e.g.,advertisements).Notification Payload—the typed contents of a notification. Payload typesmay range from simple text messages to more complex objects.Notification Handler Service Interface—the type of service providerinterface on which notifications may be received. The service provideralso describes the notification interests associated with the interface,as well as the acceptable payload types. A Node supporting thisinterface may be the final destination for the notification or anintermediary processing endpoint.Notification Processor Service—a service that is capable of matchingnotifications to interested Nodes, delivering the notifications based onsome policy.Notification Originator—a Node that sends out a notification targeted toa set of interested Nodes and/or an intermediary set of notificationprocessing Nodes.

The notification, notification interest, and notification payload arepreferably extensible. Additionally, the notification handler serviceinterface is preferably subject to the same authorization process as anyother NEMO service interface. Thus, even though a given notification maymatch in terms of interest and acceptable payload, a Node may refuse toaccept a notification based on some associated interface policy relatedto the intermediary sender or originating source of the notification.

FIG. 17 a depicts a set of notification processing Nodes 1710discovering 1715 a Node 1720 that supports the notification handlerservice. As part of its service description, node 1720 designates itsnotification interests, as well as which notification payload types areacceptable.

FIG. 17 b depicts how notifications can be delivered. Any Node could bethe originating source as well as processor of the notification, andcould be responsible for delivering the notification to Node 1720, whichsupports the notification handler service. Thus, Node 1710 a could bethe originating notification processing Node; or such functionalitymight be split between Node 1710 c (originating source of notification)and Node 1710 b (processor of notification). Still another Node (notshown) might be responsible for delivery of the notification.Notification processors that choose to handle notifications from foreignnotification-originating Nodes may integrate with a commercialnotification-processing engine such as Microsoft Notification Servicesin order to improve efficiency.

4.3. Service Discovery

In order to use NEMO services, NEMO Nodes will need to first know aboutthem. One embodiment of NEMO supports three dynamic discoverymechanisms, illustrated in FIGS. 18 a-c:

Client Driven—a NEMO Node 1810 a (in FIG. 18 a) explicitly sends out arequest to some set of targeted Nodes (e.g., 1820 a) that support a“Service Query” service interface 1815 a, the request asking whether thetargeted Nodes support a specified set of services. If requesting Node1810 a is authorized, Service Providing Node 1820 a will send a responseindicating whether it supports the requested interfaces and theassociated service interface bindings. This is one of the more commoninterfaces that Nodes will support if they expose any services.Node Registration—a NEMO Node 1810 b (in FIG. 18 b) can register itsdescription, including its supported services, with other Nodes, such asService Providing Node 1820 b. If a Node supports this interface 1815 b,it is willing to accept requests from other Nodes and then cache thosedescriptions based on some policy. These Node descriptions are thenavailable directly for use by the receiving Node or by other Nodes thatperform service queries targeted to Nodes that have cached descriptions.As an alternative to P2P registration, a Node could also utilize apublic registry, such as a UDDI (Universal Discovery, Description andIntegration) standard registry for locating services.Event-Based—Nodes (such as Node 1810 c in FIG. 18 c) send outnotifications 1815 c to Interested Nodes 1820 c (that are “notificationaware” and previously indicated their interest), indicating a change instate (e.g., Node active/available), or a Node advertises that itsupports some specific service. The notification 1815 c can contain afull description of the node and its services, or just the ID of thenode associated with the event. Interested nodes may then choose toaccept and process the notification.

4.4. Service Authorization and the Establishment of Trust

As noted above, in one embodiment, before a NEMO Node allows access to arequested service, it first determines whether, and under whichconditions, the requesting Node is permitted access to that service.Access permission is based on a trust context for interactions betweenservice requestor and service provider. As will be discussed below, evenif a Node establishes that it can be trusted, a service providing Nodemay also require that it satisfy a specified policy before permittingaccess to a particular service or set of services.

In one embodiment NEMO does not mandate the specific requirements,criteria, or decision-making logic employed by an arbitrary set of Nodesin determining whether to trust each other. Trust semantics may varyradically from Node to Node. Instead, NEMO provides a standard set offacilities that allow Nodes to negotiate a mutually acceptable trustedrelationship. In the determination and establishment of trust betweenNodes, NEMO supports the exchange of credentials (and/or relatedinformation) between Nodes, which can be used for establishing a trustedcontext. Such trust-related credentials may be exchanged using a varietyof different models, including the following:

Service-Binding Properties—a model where trust credentials are exchangedimplicitly as part of the service interface binding. For example, if aNode 1920 a (in FIG. 19 a) exposes a service in the form of an HTTP Postover SSL, or as a Web Service that requires a WS-Security XML Signature,then the actual properties of this service binding may communicate allnecessary trust-related credentials 1915 a with a Requesting Node 1910a.Request/Response Attributes—a model where trust credentials areexchanged through WSDL request and response messages (see FIG. 19 b)between a Requesting Node 1910 b and a Service Providing Node 1920 b,optionally including the credentials as attributes of the messages 1915b. For example, digital certificates could be attached to, and flowalong with, request and response messages, and could be used for forminga trusted relationship.Explicit Exchange—a model where trust credentials are exchangedexplicitly through a service-provider interface (1915 c in FIG. 19 c)that allows querying of information related to the trust credentialsthat a given node contains. This is generally the most involved model,typically requiring a separate roundtrip session in order to exchangecredentials between a Requesting Node 1910 c and a Service ProvidingNode 1920 c. The service interface binding itself provides a mutuallyacceptable trusted channel for explicit exchange of credentials.

In addition to these basic models, NEMO can also support combinations ofthese different approaches. For example, the communication channelassociated with a semi-trusted service binding may be used to bootstrapthe exchange of other security-related credentials more directly, orexchanging security-related credentials (which may have some type ofinherent integrity) directly and using them to establish a securecommunication channel associated with some service interface binding.

As noted above, trust model semantics and the processes of establishingtrust may vary from entity to entity. In some situations, mutual trustbetween nodes may not be required. This type of dynamic heterogeneousenvironment calls for a flexible model that provides a common set offacilities that allow different entities to negotiate context-sensitivetrust semantics.

4.5. Policy-Managed Access

In one embodiment (as noted above), a service providing Node, inaddition to requiring the establishment of a trusted context before itallows a requesting Node to access a resource, may also require that therequesting Node satisfy a policy associated with that resource. Thepolicy decision mechanism used for this purpose may be local and/orprivate. In one embodiment, NEMO provides a consistent, flexiblemechanism for supporting this functionality.

As part of the service description, one can designate specific NEMONodes as “authorization” service providers. In one embodiment anauthorization service providing Node implements a standard service forhandling and responding to authorization query requests. Before accessis allowed to a service interface, the targeted service providerdispatches an “Authorization” query request to any authorizing Nodes forits service, and access will be allowed only if one or more such Nodes(or a pre-specified combination thereof) respond indicating that accessis permitted.

As illustrated in FIG. 20, a Requesting Node 2010 exchanges messages2015 with a Service Providing Node 2020, including an initial requestfor a particular service. Service Providing Node 2020 then determineswhether Requesting Node 2010 is authorized to invoke that service, andthus exchanges authorization messages 2025 with the authorizing Nodes2025 that manage access to the requested service, including an initialauthorization request to these Nodes 2030. Based on the responses itreceives, Service Providing Node 2020 then either processes and returnsthe applicable service response, or returns a response indicating thataccess was denied.

Thus, the Authorization service allows a NEMO Node to participate in therole of policy decision point (PDP). In a preferred embodiment, NEMO ispolicy management system neutral; it does not mandate how an authorizingNode reaches decisions about authorizations based on an authorizationquery. Yet, for interoperability, it is preferable that authorizationrequests and responses adhere to some standard, and be sufficientlyextensible to carry a flexible payload so that they can accommodatedifferent types of authorization query requests in the context ofdifferent policy management systems. In one embodiment, support isprovided for at least two authorization formats: (1) a simple formatproviding a very simple envelope using some least common denominatorcriteria, such as input, a simple requestor ID, resource ID, and/oraction ID, and (2) the standard “Security Assertion Markup Language”(SAML) format to envelope an authorization query.

In one embodiment, an authorizing Node must recognize and support atleast a predefined “simple” format and be able to map it to whatevernative policy expression format exists on the authorizing Node. Forother formats, the authorizing Node returns an appropriate errorresponse if it does not handle or understand the payload of an“Authorization” query request. Extensions may include the ability forNodes to negotiate over acceptable formats of an authorization query,and for Nodes to query to determine which formats are supported by agiven authorizing service provider Node.

4.6. Basic DRM Node Interaction

Returning to the specific NEMO instance of a DRM application, FIG. 21 isa DRM Node (or Vertex) Graph that can serve to illustrate theinteraction among DRM Nodes, as well as their relationships. Considerthe following scenario in which portable device 2110 is a contentplayback device (e.g., an iPod1). Nip1 is the Node that represents thisdevice. Kip1 is the content encryption key associated with Nip1. “User”is the owner of the portable device, and Ng is the Node that representsthe user. Kg is the content encryption key associated with Ng.

PubLib is a Public Library. Npl represents the members of this library,and Kpl is the content encryption key associated with Npl. ACMErepresents all the ACME-manufactured Music Players. Namp represents thatclass of devices, and Kamp is the content encryption key associated withthis group.

L1 is a link from Nip1 to Ng, which means that the portable devicebelongs to the user (and has access to the user's keys). L2 is a linkfrom Ng to Npl, which means that the user is a member of the PublicLibrary (and has access to its keys). L3 is a link from Nip1 to Namp,which means that the portable device is an ACME device (mere membership,as the company has no keys). L4 is a link from Npl to Napl, which is theNode representing all public libraries (and has access to the groupwidekeys).

C1 is a movie file that the Public Library makes available to itsmembers. Kc1 is a key used to encrypt C1. GB[C1] (not shown) is thegovernance information for C1 (e.g., rules and associated informationused for governing access to the content). E(a,b) means ‘b’ encryptedwith key ‘a’.

For purposes of illustration, assume that it is desired to set a rulethat a device can play the content C1 as long as (a) the device belongsto someone who is a member of the library and (b) the device ismanufactured by ACME.

The content C1 is encrypted with Kc1. The rules program is created, aswell as the encrypted content key RK[C1]=E(Kamp, E(Kpl, Kc1)). Both therules program and RK[C1] can be included in the governance block for thecontent, GB[C1].

The portable device receives C1 and GB[C1]. For example, both might bepackaged in the same file, or received separately. The portable devicereceived L1 when the user first installed his device after buying it.The portable device received L2 when the user paid his subscription feeto the Public Library. The portable device received L3 when it wasmanufactured (e.g., L3 was built in).

From L1, L2 and L3, the portable device is able to check that Nip1 has agraph path to Ng (L1), Npl (L1+L2), and Namp (L3). The portable devicewants to play C1. The portable device runs the rule found in GB[C1]. Therule can check that Nip1 is indeed an ACME device (path to Namp) andbelongs to a member of the public library (path to Npl). Thus, the rulereturns “yes”, and the ordered list (Namp, Npl).

The portable device uses L1 to compute Kg, and then L2 to compute Kplfrom Kg. The portable device also uses L3 to compute Kamp. The portabledevice applies Kpl and Kamp to RK[C1], found in GB[C1], and computesKc1. It then uses Kc1 to decrypt and play C1.

When Node keys are symmetric keys, as in the previous examples, thecontent packager needs to have access to the keys of the Nodes to whichit wishes to “bind” the content. This can be achieved by creating a Nodethat represents the packager, and a link between that Node and the Nodesto which it wishes to bind rules. This can also be achieved “out ofband” through a service, for instance. But in some situations, it maynot be possible, or practical to use symmetric keys. In that case, it ispossible to assign a key pair to the Nodes to which a binding is neededwithout shared knowledge. In that case, the packager would bind acontent key to a Node by encrypting the content key with the targetNode's public key. To obtain the key for decryption, the client wouldhave access to the Node's private key via a link to that Node.

In the most general case, the Nodes used for the rules and the Nodesused for computing content encryption keys need not be the same. It isnatural to use the same Nodes, since there is a strong relationshipbetween a rule that governs content and the key used to encrypt it, butit is not necessary. In some systems, some Nodes may be used for contentprotection keys that are not used for expressing membership conditions,and vice versa, and in some situations, two different graphs of Nodescan be used, one for the rules and one for content protection. Forexample, a rule could say that all members of group Npl can have accessto content C1, but the content key Kc1 may not be protected by Kpl, butmay instead by protected by the node key Kapl of node Napl, whichrepresents all public libraries, not just Npl. Or a rule could say thatyou need to be a member of Namp, but the content encryption key could bebound only to Npl.

4.7. Operation of DRM Virtual Machine (VM)

The discussion with respect to FIG. 21 above described the operation ofa DRM system at a high (Node and Link) level, including the formationand enforcement of content governance policies. FIG. 22 depicts anexemplary code module 2200 of a DRM engine's VM that implements theformation and enforcement of such content governance policies.

Four main elements of illustrative Code Module 2200, shown in FIG. 22,include:

pkCM Atom: The pkCM Atom 2210 is the top-level Code Module Atom. Itcontains a sequence of sub-atoms.pkDS Atom: The pkDS Atom 2220 contains a memory image that can be loadedinto the Data Segment. The payload of the Atom is a raw sequence ofoctet values.pkCS Atom: The pkCS Atom 2230 contains a memory image that can be loadedinto the Code Segment. The payload of the Atom is a raw sequence ofoctet values.pkEX Atom: The pkEX Atom 2240 contains a list of export entries. Eachexport entry consists of a name, encoded as an 8-bit name size, followedby the characters of the name, including a terminating 0, followed by a32-bit integer representing the byte offset of the named entry point(this is an offset from the start of the data stored in the pkCS Atom).

4.7.1. Module Loader

In one embodiment, the Control VM is responsible for loading CodeModules. When a Code Module is loaded, the memory image encoded in pkDSAtom 2220 is loaded at a memory address in the Data Segment. Thataddress is chosen by the VM Loader, and is stored in the DSpseudo-register. The memory image encoded in the pkCS Atom 2230 isloaded at a memory address in the Code Segment. That address is chosenby the VM Loader, and is stored in the CS pseudo-register.

4.7.2. System Calls

In one embodiment, Control VM Programs can call functions implementedoutside of their Code Module's Code Segment. This is done through theuse of the OP_CALL instruction, that takes an integer stack operandspecifying the System Call Number to call. Depending on the System Call,the implementation can be a Control VM Byte Code routine in a differentCode Module (for instance, a library of utility functions), directly bythe VM in the VM's native implementation format, or delegated to anexternal software module, such as the VM's Host Environment.

In one embodiment, several System Call Numbers are specified: SYS_NOP=0:This call is a no-operation call. It just returns (does nothing else).It is used primarily for testing the VM.

SYS_DEBUG_PRINT=1: Prints a string of text to a debug output. This callexpects a single stack argument, specifying the address of the memorylocation containing the null-terminated string to print.SYS_FIND_SYSCALL_BY_NAME=2: Determines whether the VM implements a namedSystem Call. If it does, the System Call Number is returned on thestack; otherwise the value −1 is returned. This call expects a singlestack argument, specifying the address of the memory location containingthe null-terminated System Call name that is being requested.

4.7.3. System Call Numbers Allocation

In one embodiment, the Control VM reserves System Call Numbers 0 to 1023for mandatory System Calls (System Calls that have to be implemented byall profiles of the VM).

System Call Numbers 16384 to 32767 are available for the VM to assigndynamically (for example, the System Call Numbers returned bySYS_FIND_SYSCALL_BY_NAME can be allocated dynamically by the VM, and donot have to be the same numbers on all VM implementations).

4.7.4. Standard System Calls

In one embodiment, several standard System Calls are provided tofacilitate writing Control Programs. Such standard system calls mayinclude a call to obtain a time stamp from the host, a call to determineif a node is Reachable, and/or the like. System calls preferably havedynamically determined numbers (e.g., theft System Call Number can beretrieved by calling the SYS_FIND_SYSCALL_BY_NAME System Call with theirname passed as the argument).

4.8. Interfaces Between DRM Engine Interface and Host Application

Following are some exemplary high level descriptions of the types ofinterfaces provided by an illustrative DRM (client consumption) engineto a Host Application:

SystemName::CreateSession(hostContextObject)→Session

Creates a session given a Host Application Context. The context objectis used by the DRM engine to make callbacks into the application.

Session::ProcessObject(drmObject)

This function should be called by the Host Application when itencounters certain types of objects in the media files that can beidentified as belonging to the DRM subsystem. Such objects includecontent control programs, membership tokens, etc. The syntax andsemantics of those objects is opaque to the Host Application.

Session::OpenContent(contentReference)→Content

The host application calls this function when it needs to interact witha multimedia content file. The DRM engine returns a Content object thatcan be used subsequently for retrieving DRM information about thecontent, and interacting with such information.

Content:GetDrmInfo( )

Returns DRM metadata about the content that is otherwise not availablein the regular metadata for the file.

Content:CreateAction(actionInfo)→Action

The Host Application calls this function when it wants to interact witha Content object. The actionInfo parameter specifies what type of actionthe application needs to perform (e.g., Play), as well as any associatedparameters, if necessary. The function returns an Action object that canthen be used to perform the action and retrieve the content key.

Action::GetKeyInfo( )

Returns information that is necessary for the decryption subsystem todecrypt the content.

Action:: Check( )

Checks whether the DRM subsystem will authorize the performance of thisaction (i.e., whether Action::Perform( ) would succeed).

Action:: Perform( )

Performs the action, and carries out any consequences (with their sideeffects) as specified by the rule(s) that governs this action.

Following are some exemplary high level descriptions of the type ofinterface provided by an illustrative Host Application to a DRM (clientconsumption) engine:

HostContext:GetFileSystem(type)→FileSystem

Returns a virtual FileSystem object to which the DRM subsystem hasexclusive access.This virtual FileSystem will be used to store DRM state information. Thedata within this FileSystem is readable and writeable only by the DRMsubsystem.

HostContext:GetCurrentTime( )

Returns the current date/time as maintained by the host system.

HostContext:GetIdentity( )

Returns the unique ID of this host.

HostContext:ProcessObject(dataObject)

Gives back to the host services a data object that may have beenembedded inside a DRM object, but that the DRM subsystem has identifiedas being managed by the host (e.g., certificates).

HostContext:: VerifySignature(signatureInfo)

Checks the validity of a digital signature to a data object. Preferably,the signatureInfo object contains information equivalent to theinformation found in an XMLSig element. The Host Services areresponsible for managing the keys and key certificates necessary tovalidate the signature.HostContext::CreateCipher(cipherType, keyInfo)→CipherCreates a Cipher object that the DRM subsystem can use to encrypt anddecrypt data. A minimal set of cipher types will preferably be defined,and for each a format for describing the key info required by the cipherimplementation.

Cipher:Encrypt(data)

The Cipher object referred to above, used to encrypt data.

Cipher:Decrypt(data)

The Cipher object referred to above, used to decrypt data.

HostContext::CreateDigester(digesterType)→Digester

Creates a Digester object that the DRM subsystem can use to compute asecure hash over some data. A minimal set of digest types will bedefined.

Digester::Update(data)

The Digester object referred to above, used to compute the secure hash.

Digester:GetDigest( )

The Digester object referred to above, used to obtain the secure hashcomputed by the DRM subsystem.

Following are some exemplary high level descriptions of the type ofinterface provided by an illustrative DRM (service-side packaging)engine to a Host Application:

SystemName::CreateSession(hostContextObject)→Session

Creates a session given a Host Application Context. The context objectis used by the DRM Packaging engine to make callbacks into theapplication.

Session::CreateContent(contentReferences[ ])→Content

The Host Application will call this function in order to create aContent object that will be associated with license objects insubsequent steps. Having more than one content reference in thecontentReferences array implies that these are bound together in abundle (one audio and one video track for example), and that the licenseissued should be targeted to these as one indivisible group.

Content:SetDrmInfo(drmInfo)

The drmInfo parameter specifies the metadata of the license that will beissued. The structure will be read and will act as a guideline tocompute the license into bytecode for the VM.Content::GetDRMObjects(format)→drmObjectsThis function is called when the Host Application is ready to get thedrmObjects that the DRM Packaging engine created. The format parameterwill indicate the format expected for these objects (e.g., XML or binaryatoms).Content::GetKeys( )→keys[ ]This function is called by the Host Application when it needs the keysin order to encrypt the content. In one embodiment there will be one keyper content reference.

Following are some exemplary high level descriptions of the type ofinterface provided by an illustrative Host Application to a DRM(service-side packaging) engine:

HostContext::GetFileSystem(type)→FileSystem

Returns a virtual FileSystem object to which the DRM subsystem hasexclusive access. This virtual FileSystem would be used to store DRMstate information. The data within this FileSystem should only bereadable and writeable by the DRM subsystem.

HostContext:GetCurrentTime( )→Time

Returns the current date/time as maintained by the host system.

HostContext:GetIdentity( )→ID

Returns the unique ID of this host.HostContext::PerformSignature(signatureInfo, data)Some DRM objects created by the DRM Packaging engine will have to betrusted. This service, provided by the host, will be used to sign thespecified object.HostContext::CreateCipher(cipherType, keyInfo)→CipherCreates a Cipher object that the DRM Packaging engine can use to encryptand decrypt data. This is used to encrypt the content key data in theContentKey object.

Cipher:Encrypt(data)

The Cipher object referred to above, used to encrypt data.

Cipher:Decrypt(data)

The Cipher object referred to above, used to decrypt data.

HostContext::CreateDigester(digesterType) Digester

Creates a Digester object that the DRM Packaging engine can use tocompute a secure hash over some data.

Digester:Update(data)

The Digester object referred to above, used to comput the secure hash.

Digester::GetDigest( )

The Digester object referred to above, used to obtain the secure hashcomputed by the DRM subsystem.

HostContext:GenerateRandomNumber( )

Generates a random number that can be used for generating a key.

5. Services

5.1. Overview

Having described the NEMO/DRM system from both an architectural andoperational perspective, we now turn our attention to an illustrativecollection of services, data types, and related objects (“profiles”)that can be used to implement the functionality of the system.

As noted above, a preferred embodiment of the NEMO architecture employsa flexible and portable way of describing the syntax of requests andresponses associated with service invocation, data types used within theframework, message enveloping, and data values exposed by and usedwithin the NEMO framework. WSDL 1.1 and above provides sufficientflexibility to describe and represent a variety of types of serviceinterface and invocation patterns, and has sufficient abstraction toaccommodate bindings to a variety of different endpoint Nodes viadiverse communication protocols.

In one embodiment, we define a profile to be a set of thematicallyrelated data types and interfaces defined in WSDL. NEMO distinguishes a“Core” profile (which includes the foundational set of data types andservice messages necessary to support fundamental NEMO Node interactionpatterns and infrastructural functionality) from an application-specificprofile, such as a DRM Profile (which describes the Digital RightsManagement services that can be realized with NEMO), both of which arediscussed below.

It will be appreciated that many of the data types and services definedin these profiles are abstract, and should be specialized before theyare used. Other profiles are built on top of the Core profile.

5.2. NEMO Profile Hierarchy

In one embodiment, the definition of service interfaces and related datatypes is structured as a set of mandatory and optional profiles thatbuild on one another and may be extended. The difference between aprofile and a profile extension is a relatively subtle one. In general,profile extensions don't add new data types or service type definitions.They just extend existing abstract and concrete types.

FIG. 23 illustrates an exemplary profile hierarchy for NEMO and DRMfunctionality. The main elements of this profile hierarchy include:

Core Profile—At the base of this profile hierarchy lies Core Profile2300, which preferably shares both NEMO and DRM functionality. This isthe profile on which all other profiles are based. It includes a basicset of generic types (discussed below) that serve as the basis forcreating more complex types in the framework. Many of the types in theCore Profile are abstract and will need to be specialized before use.Core Profile Extensions—Immediately above Core Profile 2300 are the CoreProfile Extensions 2320, which are the primary specializations of thetypes in Core Profile 2300, resulting in concrete representations.Core Services Profile—Also immediately above Core Profile 2300, the CoreServices Profile 2310 defines a set of general infrastructure services,also discussed below. In this profile, the service definitions areabstract and will need to be specialized before use.Core Services Profile Extensions—Building upon both Core ProfileExtensions 2320 and Core Services Profile 2310 are the Core ServicesProfile Extensions 2330, which are the primary specializations of theservices defined in Core Services Profile 2310, resulting in concreterepresentations.DRM Profile—Immediately above Core Profile 2300 lies DRM Profile 2340,upon which other DRM-related profiles are based. DRM Profile 2340includes a basic set of generic types (discussed below) that serve asthe basis for creating more complex DRM-specific types. Many of thetypes in DRM Profile 2340 are abstract and will need to be specializedbefore use.DRM Profile Extensions—Building upon DRM Profile 2340 are the DRMProfile Extensions 2350, which are the primary specializations of thetypes in DRM Profile 2340, resulting in concrete representations.DRM Services Profile—Also building upon DRM Profile 2340 is DRM ServicesProfile 2360, which defines a set of general DRM services (discussedbelow). In this profile, the service definitions are abstract and needto be specialized before use.Specific DRM Profile—Building upon both DRM Profile Extensions 2350 andDRM Services Profile 2360 is the Specific DRM Profile 2370, which is afurther specialization of the DRM services defined in DRM ServicesProfile 2360. This profile also introduces some new types and furtherextends certain types specified in Core Profile Extensions 2320.

5.3. NEMO Services and Service Specifications

Within this profile hierarchy lies, in one embodiment, the followingmain service constructs (as described in more detail above):

Peer Discovery—the ability to have peers in the system discover oneanother.Service Discovery—the ability to discover and obtain information aboutservices offered by different peers.Authorization—the ability to determine if a given peer (e.g., a Node) isauthorized to access a given resource (such as a service).Notification—services related to the delivery of targeted messages,based on specified criteria, to a given set of peers (e.g., Nodes).Following are definitions (also discussed above) of some of the main DRMconstructs within this example profile hierarchy:Personalization—services to obtain the credentials, policy, and otherobjects needed for a DRM-related endpoint (such as a CE device, musicplayer, DRM license server, etc.) to establish a valid identity in thecontext of a specific DRM system.Licensing Acquisition—services to obtain new DRM licenses.Licensing Translation—services to exchange one new DRM license formatfor another.Membership—services to obtain various types of objects that establishmembership within some designated domain.

The NEMO/DRM profile hierarchy can be described, in one embodiment, as aset of Generic Interface Specifications (describing an abstract set ofservices, communication patterns, and operations), Type Specifications(containing the data types defined in the NEMO profiles), and ConcreteSpecifications (mapping abstract service interfaces to concrete onesincluding bindings to specific protocols). One embodiment of thesespecifications, in the form of Service Definitions and Profile Schemes,is set forth in Appendix 1 (C) hereto.

6. Additional Application Scenarios

FIG. 24 illustrates a relatively simple example of an embodiment of NEMOin operation in the context of a consumer using a new music player toplay a DRM-protected song. As shown below, however, even this simpleexample illustrates many different potential related applicationscenarios. This example demonstrates the bridging of discoveryservices—using universal plug and play (UPnP) based service discovery asa mechanism to find and link to a UDDI based directory service. It alsodetails service interactions between Personal Area Network (PAN) andWide Area Network (WAN) services, negotiation of a trusted context forservice use, and provisioning of a new device and DRM service.

Referring to FIG. 24, a consumer, having bought a new music player 2400,desires to play a DRM-protected song. Player 2400 can support this DRMsystem, but needs to be personalized. In other words, Player 2400,although it includes certain elements (not shown) that render it bothNEMO-enabled and DRM-capable, must first perform a personalizationprocess to become part of this system.

Typically, a NEMO client would include certain basic elementsillustrated in FIGS. 5 a and 6 above, such as a Service Access Point toinvoke other Node's services, Trust Management Processing to demonstratethat it is a trusted resource for playing certain protected content, aswell as a Web Services layer to support service invocations and thecreation and receipt of messages. As discussed below, however, not allof these elements are necessary to enable a Node to participate in aNEMO system.

In some embodiments, client nodes may also include certain basicDRM-related elements, as illustrated in FIGS. 12 a and 13-15 above, suchas a DRM client engine and cryptographic services (and related objectsand cryptographic keys) to enable processing of protected content,including decrypting protected songs, as well as a media renderingengine to play those songs. Here, too, some such elements need not bepresent. For example, had Player 2400 been a music player that was onlycapable of playing unprotected content, it might not require the corecryptographic elements present in other music players.

More specifically, in the example shown in FIG. 24, Player 2400 iswireless, supports the UPnP and Bluetooth protocols, and has a set ofX.509 certificates it can use to validate signatures and sign messages.Player 2400 is NEMO-enabled in that it can form and process a limitednumber of NEMO service messages, but it does not contain a NEMO ServiceAccess Point due to resource constraints.

Player 2400, however, is able to participate in a Personal Area Network(PAN) 2410 in the user's home, which includes a NEMO-enabled,Internet-connected, Home Gateway Device 2420 with Bluetooth and a NEMOSAP 2430. The UPnP stacks of both Player 2400 and Gateway 2420 have beenextended to support a new service profile type for a “NEMO-enabledGateway” service, discussed below.

When the user downloads a song and tries to play it, Player 2400determines that it needs to be personalized, and initiates the process.For example, Player 2400 may initiate a UPnP service request for a NEMOgateway on PAN 2410. It locates a NEMO gateway service, and Gateway 2420returns the necessary information to allow Player 2400 to connect tothat service.

Player 2400 then forms a NEMO Personalization request message and sendsit to the gateway service. The request includes an X.509 certificateassociated with Player 2400's device identity. Gateway 2420, uponreceiving the request, determines that it cannot fulfill the requestlocally, but has the ability to discover other potential serviceproviders. However, Gateway 2420 has a policy that all messages itreceives must be digitally signed, and thus it rejects the request andreturns an authorization failure stating the policy associated withprocessing this type of request.

Player 2400, upon receiving this rejection, notes the reason for thedenial of service and then digitally signs (e.g., as discussed above inconnection with FIG. 15) and re-submits the request to Gateway 2420,which then accepts the message. As previously mentioned, Gateway 2420cannot fulfill this request locally, but can perform service discovery.Gateway 2420 is unaware of the specific discovery protocols its SAP 2430implementation supports, and thus composes a general attribute-basedservice discovery request based on the type of service desired(personalization), and dispatches the request via SAP 2430.

SAP 2430, configured with the necessary information to talk to UDDIregistries, such as Internet-Based UDDI Registry 2440, converts therequest into a native UDDI query of the appropriate form and sends thequery. UDDI Registry 2440 knows of a service provider that supports DRMpersonalization and returns the query results. SAP 2430 receives theseresults and returns an appropriate response, with the necessary serviceprovider information, in the proper format, to Gateway 2420.

Gateway 2420 extracts the service provider information from the servicediscovery response and composes a new request for Personalization basedon the initial request on behalf of Player 2400. This request issubmitted to SAP 2430. The service provider information (in particular,the service interface description of Personalization Service 2450)reveals how SAP 2430 must communicate with a personalization servicethat exposes its service through a web service described in WSDL. SAP2430, adhering to these requirements, invokes Personalization Service2450 and receives the response.

Gateway 2420 then returns the response to Player 2400, which can use thepayload of the response to personalize its DRM engine. At this point,Player 2400 is provisioned, and can fully participate in a variety oflocal and global consumer oriented services. These can provide fullvisibility into and access to a variety of local and remote contentservices, lookup, matching and licensing services, and additionalautomated provisioning services, all cooperating in the service of theconsumer. As explained above, various decryption keys may be necessaryto access certain protected content, assuming the consumer and Player2400 satisfy whatever policies are imposed by the content provider.

Thus, a consumer using a personal media player at home can enjoy thesimplicity of a CE device, but leverage the services provided by bothgateway and peer devices. When the consumer travels to another venue,the device can rediscover and use most or all of the services availableat home, and, through new gateway services, be logically connected tothe home network, while enjoying the services available at the new venuethat are permitted according to the various policies associated withthose services. Conversely, the consumer's device can provide servicesto peers found at the new venue.

Clearly, utilizing some or all of these same constructs (NEMO Nodes,SAPs, Service Adaptation Layers, various standards such as XML, WSDL,SOAP, UDDI, etc.), many other scenarios are possible, even within therealm of this DRM music player example. For example, Player 2400 mighthave contained its own SAP, perhaps eliminating the need for Gateway2420. UDDI Registry 2440 might have been used for other purposes, suchas locating and/or licensing music content. Moreover, many other DRMapplications could be constructed, e.g., involving a licensing schemeimposing complex usage and distribution policies for many differenttypes of audio and video, for a variety of different categories ofusers. Also, outside of the DRM context, virtually any otherservice-based applications could be constructed using the NEMOframework.

As another example, consider the application of NEMO in a businesspeer-to-peer environment. Techniques for business applicationdevelopment and integration are quickly evolving beyond the limits oftraditional tools and software development lifecycles as practiced inmost IT departments. This includes the development of word processingdocuments, graphic presentations, and spreadsheets. While some woulddebate whether these documents in their simplest form represent trueapplications, consider that many forms of these documents have welldefined and complex object models that are formally described. Suchdocuments or other objects might include, for example, state informationthat can be inspected and updated during the lifecycle of the object,the ability for multiple users to work on the objects concurrently,and/or additional arbitrary functionality. In more complicatedscenarios, document-based information objects can be programmaticallyassembled to behave like full-fledged applications.

Just as with traditional software development, these types of objectscan also benefit from source control and accountability. There are manysystems today that support document management, and many applicationsdirectly support some form of document control. However most of thesesystems in the context of distributed processing environments exhibitlimitations, including a centralized approach to version management withexplicit check-in and checkout models, and inflexible (very weak or veryrigid) coherence policies that are tied to client rendering applicationsor formats particularly within the context of a particular application(e.g., a document).

Preferred embodiments of NEMO can be used to address these limitation bymeans of a P2P policy architecture that stresses capability discoveryand format negotiation. It is possible to structure the creation of anapplication (e.g., a document) in richer ways, providing multipleadvantages. Rich policy can be applied to the objects and to thestructure of the application. For example, a policy might specify someor all of the following:

-   -   Only certain modules can be modified.    -   Only object interfaces can be extended or implementations        changed.    -   Deletions only allowed but not extensions.    -   How updates are to be applied, including functionality such as        automatic merging of non-conflicting updates, and application of        updates before a given peer can send any of its updates to other        peers.    -   Policy-based notification such that all peers can be notified of        updates if they choose, in order to participate in direct        synchronization via the most appropriate mechanisms.    -   Support updates from different types of clients based on their        capabilities.

In order to achieve this functionality, the authoring application usedby each participant can be a NEMO-enabled peer. For the document that iscreated, a template can be used that describes the policy, including whois authorized and what can be done to each part of the document (inaddition to the document's normal formatting rules). As long as thepolicy engine used by the NEMO peer can interpret and enforce policyrules consistent with their semantics, and as long as the operationssupported by the peer interfaces allowed in the creation of the documentcan be mapped to a given peer's environment via the Service AdaptationLayer, then any peer can participate, but may internally represent thedocument differently.

Consider the case of a system consisting of different NEMO peers usingservices built on the NEMO framework for collaboration involving apresentation document. In this example, a wireless PDA application isrunning an application written in Java, which it uses for processing andrendering the document as text. A different implementation running underMicrosoft Windows® on a desktop workstation processes the same documentusing the Microsoft Word® format. Both the PDA and the workstation areable to communicate, for example, by connection over a local areanetwork, thus enabling the user of the PDA and the user of theworkstation to collaborate on the same document application. In thisexample:

-   -   NEMO peers involved in the collaboration can discover each        other, their current status, and their capabilities.    -   Each NEMO peer submits for each committable change, its        identity, the change, and the operation (e.g., deletion,        extension, etc.).    -   All changes are propagated to each NEMO peer. This is possible        because each NEMO peer can discover the profile and capabilities        of another peer if advertised. At this point the notifying peer        can have the content change encoding in a form acceptable by the        notified peer if it is incapable of doing so. Alternatively the        accepting peer may represent the change in any format it sees        fit upon receipt at its interface.    -   Before accepting a change the peer verifies that it is from an        authorized NEMO participant.    -   The change is applied based on the document policy.

As another example, consider the case of a portable wireless consumerelectronics (CE) device that is a NEMO-enabled node (X), and thatsupports DRM format A, but wants to play content in DRM format B. Xannounces its desire to render the content as well as a description ofits characteristics (e.g., what its identity is, what OS it supports,its renewability profile, payment methods it supports, and/or the like)and waits for responses back from other NEMO peers providing potentialsolutions. In response to its query, X receives three responses:

-   -   (1) Peer 1 can provide a low quality downloadable version of        content in clear MP3 form for a fee of $2.00.    -   (2) Peer 2 can provide high quality pay-per-play streams of        content over a secure channel for $0.50 per play.    -   (3) Peer 3 can provide a software update to X that will permit        rendering of content in DRM format B for a fee of $10.00.

After reviewing the offers, X determines that option one is the bestchoice. It submits a request for content via offer number one. Therequest includes an assertion for a delegation that allows Peer 1 todeduct $2.00 from X's payment account via another NEMO service. Once Xhas been charged, then X is given back in a response from Peer 1 a tokenthat allows it to download the MP3 file.

If instead, X were to decide that option three was the best solution, asomewhat more complicated business transaction might ensue. For example,option three may need to be represented as a transactional businessprocess described using a NEMO Orchestration Descriptor (NOD)implemented by the NEMO Workflow Collator (WFC) elements contained inthe participating NEMO enabled peers. In order to accomplish thenecessary software update to X, the following actions could be executedusing the NEMO framework:

-   -   X obtains permission from its wireless service provider (B) that        it is allowed to receive the update.    -   Wireless service provider B directly validates peer three's        credentials in order to establish its identity.    -   X downloads from B a mandatory update that allows it to install        3rd party updates, their is no policy restriction on this, but        this scenario is the first triggering event to cause this        action.    -   X is charged for the update that peer three provides.    -   X downloads the update from peer three.

In this business process some actions may be able to be carried outconcurrently by the WFC elements, while other activities may need toauthorized and executed in a specific sequence.

Yet another example of a potential application of the NEMO framework isin the context of online gaming. Many popular multiplayer gamingenvironment networks are structured as centralized, closed portals thatallow online garners to create and participate in gaming sessions.

One of the limitations of these environments is that the users generallymust have a tight relationship with the gaming network and must have anaccount (usually associated with a particular game title) in order touse the service. The typical gamer must usually manage several gameaccounts across multiple titles across multiple gaming networks andinteract with game-provider-specific client applications in order toorganize multiple player games and participate within the networks. Thisis often inconvenient, and discourages online use.

Embodiments of the NEMO framework can be used to enhance the onlinegaming experience by creating an environment that supports a morefederated distributed gaming experience, making transparent to the userand the service provider the details of specific online game networks.This not only provides a better user experience, thereby encouragingadoption and use of these services, but can also reduce theadministrative burden on game network providers.

In order to achieve these benefits, gaming clients can be personalizedwith NEMO modules so that they can participate as NEMO peers. Moreover,gaming networks can be personalized with NEMO modules so that they canexpose their administrative interfaces in standardized ways. Finally,NEMO trust management can be used to ensure that only authorized peersinteract in intended ways.

For example, assume there are three gaming network providers A, B, andC, and two users X and Y. User X has an account with A, and User Y hasan account with B. X and Y both acquire a new title that works with Cand want to play each other. Using the NEMO framework, X's gaming peercan automatically discover online gaming provider C. X's accountinformation can be transmitted to C from A, after A confirms that C is alegitimate gaming network. X is now registered with C, and can beprovisioned with correct tokens to interact with C. User Y goes throughthe same process to gain access to C using its credentials from B. Onceboth X and Y are registered they can now discover each other and createan online gaming session.

This simple registration example can be further expanded to deal withother services that online gaming environments might provide, including,e.g., game token storage (e.g., in lockers), account payment, and sharedstate information such as historical score boards.

While several examples were presented in the context of enterprisedocument management, online gaming, and media content consumption, itwill be appreciated that the NEMO framework and the DRM system describedherein can be used in any suitable context, and are not limited to thesespecific examples.

APPENDIX 1 (A) Systems and Methods for Peer-to-Peer ServiceOrchestration APPENDIX 1 (B) Digital Rights Management Engine Systemsand Methods

Although the foregoing has been described in some detail for purposes ofclarity, it will be apparent that certain changes and modifications maybe practiced within the scope of the appended claims. It should be notedthat there are many alternative ways of implementing both the processesand apparatuses of the present inventions. Accordingly, the presentembodiments are to be considered as illustrative and not restrictive,and the inventive body of work is not to be limited to the details givenherein, but may be modified within the scope and equivalents of theappended claims.

1. A system comprising: means for encrypting a piece of electronic content; means for associating a license with the piece of electronic content, the license comprising a control program, the control program requiring, as a condition of authorizing decryption of the piece of electronic content, possession of a set of one or more link objects logically connecting a first node object with a second node object, the license further comprising an encrypted version of a first key for use in decrypting the piece of electronic content; means for sending the piece of electronic content to a remote computer system; means for determining that the remote computer system has possession of a set of one or more link objects logically connecting the first node object with the second node object, wherein at least one of the one or more link objects comprises an encrypted version of a second key for use in decrypting the first key; means for decrypting the second key using a key associated with the remote computer system; means for decrypting the first key using the second key; and means for decrypting the piece of electronic content using the first key.
 2. The system of claim 1, in which the license further comprises a controller object securely binding the control program with the first key.
 3. The system of claim 2, in which the controller object include a hash of a content key object and a control object, wherein the content key object comprises an encrypted version of the first key, and the control object comprises the control program.
 4. A computer-readable medium comprising program code, the program code being operable, when executed by a computer system, to cause the computer system to perform actions comprising: encrypting a piece of electronic content; associating a license with the piece of electronic content, the license comprising a control program, the control program requiring, as a condition of authorizing decryption of the piece of electronic content, possession of a set of one or more link objects logically connecting a first node object with a second node object, the license further comprising an encrypted version of a first key for use in decrypting the piece of electronic content; sending the piece of electronic content to a remote computer system; 